MAC~TR-18 (THESIS) 


MASSACHUSETTS INSTITUTE OF TECHNOLOGY 


Project MAC 


AN ANALYSIS OF TIME-SHARED COMPUTER SYSTEMS 
by 


Allan Lee Scherr 


June 1965 


This blank page was inserted to preserve pagination. 


AN ANALYSIS OF TIME-SHARED COMPUTER SYSTEMS 
by 
ALLAN LEE SCHERR 
S.B., Massachusetts Institute of Technology 
(1962) 


S.M., Massachusetts Institute of Technology 
(1962) 


SUBMITTED IN PARTIAL FULFILLMENT 
OF THE REQUIREMENTS FOR THE 
DEGREE OF DOCTOR OF 
PHILOSOPHY 
at the 
MASSACHUSETTS INSTITUTE OF 
TECHNOLOGY 
JUNE, 196 


y 


Signature of Author. ccccccccsccrbhocsccsevecccsces . Secesce 
Department of Electrical Engineering 
May 14, 196 


Certified Dy cccccccccccccee 


Accepted DY cele caicstecNeess ccs ee ne Cait sere ale cweew eesvseceeseeaeseoeeeesene 
Chairman, Departmental Committee 
on Graduate Students 


This empty page was substituted for a 
blank page in the original document. 


ABSTRACT 


"An Analysis of Time-Shared Computer Systems" 
Allan Lee Scherr 


Submitted to the Department of Electrical Engineering 


in partial fulfillment of the requirement for the degree 


of Doctor of Philosophy. 


Some of the aspects of the operation of time- 
shared, interactive computer systems are analyzed. 
The emphasis is on the reaction of hardware systems 
to the demands that its users make upon it. Simply 
stated, the problem is to characterize both time- 
shared systems and their users in order to be able 
to predict the performance of the two operating to- 
gether. Portions of this problem include the speci- 
fication and measurement of user characteristics, 
the development and verification of both simulation 
and mathematical models for time-shared systems, 
and the specification and measurement of performance 
metrics for such systems. The user and some of. the 
performance measurements were made on Project MAC's 
"Compatible Time-Sharing System" (CTSS). 


First, simulation models are used to study the 
effects of changing small details in the operation 
of CTSS-like systems. Then, a continuous-time Markov 
process model is derived to predict the performance 
of a broad class of systems. Throughout, the CTSS 
data are used as a basis for comparison with model 
predictions. In order to be able to take measure- 
ments and to build models, many definitions of 
commonly used time-shared system terminology are 
made precise. 
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1. 
I. INTRODUCTION 


Computer systems which are able to serve a single 
user in a conversational or interactive manner have been 
in existence for relatively many years. Lately, for 
economic and other reasons, interactive computer systems 
have been implemented to simultaneously serve many users. 
At any given time in the operation of such a system, some 
portion of the interacting users may require particular 
programs to be executed. The function of the computer 
system is to execute these programs in such a way as to 
provide "reasonable" service to each user's requirement. 

A widely-used technique for providing this type of service 
is called "time-sharing", and consists of executing each 
user's program in some order, for some time, not necessarily 
to completion. Typically, a particular user's program 

will be allowed to use a processor for a period of time, 
will be stopped so that another user's program can run, 

and then at some later time will be continued from the 

point where it was stopped. In order to be able to continue 
@ program, its status must be saved when it is stopped 

and restored when it is resumed. At the point in time 

when one user's program is stopped and another's resumed, 
the status of the former must be saved and that of the 


latter restored. This process is called "swapping". In 


ee 


general, the status of a program consists of the state 
of the processor as well as a copy of every instruction 
in the program. 

The primary aim of the research reported here is to 
develop techniques and models for the analysis of a broad 
class of interactive, time-shared computer systems. The 
emphasis is on the reaction of a hardware system to the 
demands made upon it by its users. Segments of the overall 
problem include: the specification of a model for and 
the measurement of user behavior, the development and 
verification of both mathematical and simulation models 
of time-shared systems, and the specification and measure- 
ment of performance metrics for time-shared systems. The 
user and some of the performance measurements were made 
on Project MAC's "Compatible Time-Sharing System" (here- 
after referred to as"CTSS", see CORBATO, 1962 and SALTZER, 
1965). 

The model development is divided into two phases. 
First, simulation models are used to study in detail the 
effects of small changes in the operation of CTSS-like 
systems. Then, continuous-time Markov processes are used 
to model more general classes of time~shared systems. 
Throughout, the CTSS measurements are used as a basis of 
comparison with the model predictions. 

The primary result obtained is that it is possible 
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to successfully model users of interactive computer 
systems and the systems themselves with a good degree 

of accuracy using relatively simple models. Moreover, 
many of the results obtained and most of the techniques 
developed are applicable to the analysis of a broad class 
of interactive systems. This fact is established and 
discussed in the Conclusions (Section V). 

Since human users are an integral part of any inter- 
active system, no real progress can be made in the analysis 
of the performance of such systems until the behavior of 
its users is established. The CTSS user characteristics 
were measured and modeled and are presented in Section II. 
The user model is represented as being the composite of 
the models for users working on a "mix" of different tasks. 
Thus, to a certain extent, models for a different type of 
user than those studied can be generated by using a diff- 
erent task mix. 

The models for the hardware-software time-shared 
systems are divided into two classes, (Section III). First, 
simulation models are used to study three systems: (1) cTSssS, 
(2) CTSS modified by the replacement of its scheduling 
procedure by a simple round-robin, and (3) a time-shared 
system using the CTSS hardware but using some multi-programn- 
ing techniques to improve hardware efficiency. Using the 


operation of these simulation models, detailed measurements 
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are made of several performance parameters and hardware 
usage (Section IV). Where possible, simulation results 
are also compared to actual CTSS measurements for verifi- 
cation. 

A simple continuous-time Markov model for single 
and multiple processor time-shared systems is derived 
for the purpose of predicting the mean of one of the 
performance measures, (Section III). The accuracy of 
the values predicted by these models is established by 
comparing them to the CTSS measurements. Then, using 
the Markov models, several examples of multiple-processor 
time-shared systems are investigated, (Section IV). 

The Conclusions (Section V) discuss the generality 
of the techniques and models used as well as the specific 
results obtained. It is shown that a broad class of 
systems has been covered by the techniques presented, the 
extension of these techniques to other systems is dis- 
cussed, and observations are made about the operation of 


CTSS-like systems. 


II. THE CTSS ENVIRONMENT 


The CTSS environment consists of approximately 250 
users whose individual load on the system varies from 
nearly zero up to the equivalent of several hours of IBM 
7094 time per month. The model of this environment con- 
sists of a description of what a single user does during 
an elementary operation at his console, the interaction. 
Simply stated, an interaction consists of the user re- 
questing and then receiving service from the system. 

The usual form of an interaction is the user's thinking, 
typing input at his remote console, waiting for a res- 
ponse from the system, and finally watching output. 
From the point of view of the time-shared system, the 
user may be thought of as being in one of two states: 
either the user is waiting for the system to respond, 
or the system is waiting for the user. Since the func- 
tion of a time-shared system is to execute programs 

at the request of its users, these states may be re- 
phrased as: either the system does or does not have 

& program to execute for a particular user. An inter- 
action can now be precisely defined as the events 
occurring between two successive exits from the state 
in which the system has a program to execute for the 


user. 
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The primary purpose for the development of a user 
model is its incorporation into models of complete time- 
shared systems. The most important requirement for these 
models is that they reproduce the activities of a real 
system during several hours of operation. These models 
will be required to faithfully reproduce distributions 
of service times, hardware usage, etc. Fidelity of the 
model's minute-to-minute operation is of secondary im- 
portance. 

In this section, the user interaction model is com- 
pletely described, next the inherent compromises with 
reality in the model are discussed, and finally the limi- 
tations on this type of model are outlined. It is assumed 
that the reader has some knowledge of the operation and 
hardware configuration of CTSS. However, Appendix A 
describes the operation of this system in detail suffi- 
cient to enable understanding of the remainder of this 
report. 

The data presented in this section was taken between 
December 29, 1964 and February 4, 1965, during 112 hours 
of weekday 9:00 A.M. to 5:00 P.M. operation. Approxi- 
mately 80,000 commands were monitored. The day-to-day 
changes in the data were slight, and there was stability 
in the system as well as user behavior for the duration 
of the monitoring. A more detailed discussion of these 


considerations appears at the end of this section. 


A. The Composite Interaction Model 


The two states of the user during an interaction 
have a definite correspondence to the six user states 
internal to CTSS. The part of the interaction during 
which the system has a program to execute for the user 
corresponds exactly to the "Working" state and the 
"Command Wait" state. This portion of the interaction 
will be called "the working part of the interaction". 
The other part of the interaction corresponds to the 
"Dead", "Dormant", "Input Wait", and "Output Wait" 
states, and will be called "the console part of the 
interaction". This name is due to the fact that the 
time which the user spends in this part of the inter- 
action is primarily determined by console operations. 
Exit from either the Dead or Dormant states is caused by 
the user completing a line of input which is interpreted 
as a command by the CTSS supervisory program. A line 
of input for the program serving the user terminates the 
Input Wait period. Output Wait lasts until the console 
output buffers empty. 

The event marking the transition from the working 
part of one interaction to the console part of the next 
is the completion of the program serving the user. The 
nature of this completion determines what happens during 


the following console portion. The program may require 


input from the console, it may have attempted to add 
to an already full output buffer, or it may terminate. 
In addition, a program may enter the Dormant state for 
a& program-specified period of time. The subsequent 
transition from the console part to the working part 
occurs at the end of this "sleeping" period. A program- 
generated command will be considered as a new interac- 
tion with a zero console portion. 

Thus, one transition can be tied to the event of 
& program's finishing, the other, usually to an event 
at the console (i.e., end of an input line or output 
buffers at a certain level). The importance of the 
other console events, i.e., the beginning and end of 
output, the beginning of input, etc., to the operation 
of the system is slight. Moreover, the volume of input- 
output is negligible. Even fifty consoles transmitting 
or receiving at fifteen characters per second yield a 
total rate of only 750 characters per second. This 
figure is a maximum; the average rate on CTSS is closer 
to 100 to 150 characters per second. Furthermore, there 
is no relation of these other console events to anything 
of importance within the system. For example, output 
started during the working part of the interaction 
usually overlaps into the console part. Naturally, higher 


data rate consoles, based on devices other than key- 


9. 


boards and typewriters, are possible but will not be 
considered. Appendix B contains statistics describing 
console input-output. No further separation of console 
I/O and the time the user spends thinking, etc. will 
be made; and, in fact, all of these activities will be 
lumped under the term "thinking". 

The description of the user during the console 
part of an interaction is simply the elapsed time from 
start to finish of this portion and the specification 
of the cause of the last program completion. The time 
will be specified by a probability distribution. The 
nature of the program completion marking the beginning 
of the console portion indicates what the user is doing 
during this portion. It is necessary to know, for 
example, whether a new program will be started, i.e., a 
new command, or the old one continued, etc. The dis- 
tribution of the time a user requires for the console 
part of the interaction is shown in Figure 1. The mean 
value of this time was determined to be 35.2 seconds. 
The following table shows the relative probabilities 
for the various reasons that a user is in the console 
part of an interaction. These probabilities are gener- 
ally not independent from interaction to interaction, 


as will be seen. 


PROBABILIT 


IMPULSE 
DENSITY D AREA = 012. 
No. of Data Points 238,308 
Mean 35.2 sec. 
Standard Deviation 23. sec, 
of Median ll. sec, 


Median 


“OT 


Figure 1 : PROBABILITY DENSITY OF TIME FOR CONSOLE PART OF INTERACTION 
("THINK TIME) 


ll. 


Activity during console part of interaction Probability 


User typing the next command (Dead or Dormant 223 

User typing program input (Input Wait) — 258 

Program waiting for output buffers to empty 005 
(Output Wait) 

Program "sleeping" (Dormant) -O1 

Program-generated command 12 


The time distribution shown in Figure 1 can be 
divided into several different phenomena. The impulse 
of area .12 at time zero represents the zero console 
time required for program-generated commands. The high 
probability between zero and two seconds is caused pri- 
marily by the easily typed, trivial responses, such as 
merely a carriage return, in Input Wait. A user is in 
Dead or Dormant (typing a command) for at least three 
seconds. This is due to the fact that a user must wait 
until a "ready" message is typed (ten to fifteen char- 
acters taking approximately one second) and then type 
the several characters constituting the command word. 
The line of input for Input Wait, however, may consist 
of only a carriage return character. The second high- 
probability area at around seven seconds is due to users 
making non-trivial responses at their maximum rate. Super- 


imposed onto these maxima is an extensive uniformly dis- 
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tributed time caused by both the responses which require 
the user to stop to think and the time that a user is in 
the Output Wait state. 

An important statistic about the nature of the user's 
activity during the console part of the interaction is 
whether or not a new command is coming next. In addition, 
it is important to know whether or not the user is in the 
Dead or Dormant state (i.e., whether or not a core-image 
is being saved on the drum). Figure 2 shows the distri- 
bution of the number of interactions per command. Note 
that the probability of having another interaction of a 
command is not independent of the number of interactions 
preceding it. The average number of interactions per 
command is 2.8 . The ratio of entries to Dead versus 
Dormant is .8 to .2. 

During the time a user is in the working portion of 
the interaction he is loading the system. The amount of 
time that the user remains in this state is determined 
by how much of a load the system is already carrying (in 
the form of other users working) and the amount of work 
this user requires. A user's loading during the working 
part of an interaction will be described by two parameters: 
the amount of processor time required by the user's pro- 
gram during the interaction and the size of the program. 


The size of the program determines how long it will take 


PROBABILITY 
DENSITY 


No. of Data Points 
Mean 
Median 


o% 
Median 


aw” -Mean 


5 
INTERACTIONS PER COMMAND 


Figure 2 : PROBABILITY DENSITY OF INTERACTIONS PER COMMAND 


84,697 
2.8 
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a. 


for the system to swap the user's program in and out of 
core memory and/or how many other user's programs are 
able to fit simultaneously into a core memory with it. 
Ordinarily, the size of a user's program remains constant 
for the duration of the command. The user's program may 
change size in CTSS, but this will be ignored in the model. 
The probability distribution of program size, shown in 
Figure 3, reflects measurements made at the end of a com- 
mand, i.e., on the program's entry to either the Dead or 
Dormant state. The average program size was determined 
to be 6.3 x 10° words. The parameter of processor time 
was chosen to reflect the user's processing requirements 
because of its simplicity. Because there is no signifi- 
cant overlapping of processor and channel operation in 
CTSS, the processor runs at a nearly constant rate. The 
time that a user requires the processor for an interac- 
tion includes any overhead computation needed by the sys- 
tem and access and transmission times for the user's pro- 
gram to access the disk storage. Swapping time is not 
included in the processor time since it is a function of 
the time-shared system and not of the user. System over- 
head includes scheduling and the continuous processing of 
console input. These functions are almost uniformly dis- 
tributed, degrading the processor's execution rate by 


almost a constant. Disk storage is used by the user's 


PROBABILITY 


DENSITY 
00S 
oo} 
No. of Data Points 37,632 
Mean 6.3K words 
Standard Deviation 9. K words 
ee Median 1.5K words 


002 


{@,009 28,006 30,000 
PROGRAM SIZE (Number of words) 


Figure 3.: PROBABILITY DENSITY OF PROGRAM SIZES 


Ct 
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programs much in the same way as tapes are used on @ con- 
ventional batch-processed system. The breakdown between 
overhead computation, disk usage, and normal computation 
will be discussed later. The distribution of processor 
time per interaction is shown in Figure 4 and has a mean 
of .88 seconds. 

There is really no need to know anything more about 
a user's processing needs than the amount of time re- 
quired. Typically, a program receives control of the 
processor for about two to four seconds at a time. During 
this period, several hundreds of thousands of instructions 
Will be executed. Clearly if the structure of second-to- 
second operation is not important, no instruction mixes, 
etc. are required. However, if channel operation overlaps 
processor operation to the extent that the rate of instruc- 
tion execution is affected, or if multiple, special-pur- 
pose processors are used in a time-shared system, infor- 
mation concerning instruction mixes, command types, etc. 


is desirable. Such information is discussed next. 
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PROBABILITY 
DENSITY 
Py 
ob 
No. of Data Points 237,645 
Mean -88 sec, 
5S Standard Deviation -7 sec, 
Median is less than .05 sec. 


4. z. 
PROCESSOR TIME (Seconds) 


Figure 4 :; PROBABILITY DENSITY OF PROCESSOR TIME PER 
INTERACTION 
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B. Limitations and Possible Extensions of the User Model 


Ce ned 


In order to develop the interaction model, many sim- 
piifications of reality have had to be made. The following 
paragraphs discuss these simplifications and attempt to 
justify them from CTSS data and other reasoning. Some 
possible expansions of the interaction model are discuss- 
ed. In addition, the effects of these simplifications 
on the behavior of the model are outlined. 

The first simplification is to consider all users 
as equal in the sense that all are representable by the 
same model. The interaction model tends to average out 
the differences between individual users. However, since 
there may be as many as thirty or forty consoles being 
used simultaneously and since there is a considerable turn- 
over in this user population (approximately 30 per cent 
per hour), no Significant long-term errors should result. 
The model will also tend to smooth out the effects of 
users working in bursts. That is, users sometimes have 
flurries of activity, working at a high rate, followed 
by periods of comparitive inactivity. 

The next simplification is that there is no depen- 
dence of the model on the total number of users sharing 
the system. Data shows that user loading, as reflected 
by the time in the console part of the interaction and 


the processor time per interaction, is relatively insen- 
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sitive to the number of users sharing the system. More- 
over, there has been very little drift in the means of 
the user parameters during the two months that the data 
was taken. Changes in the system tend to effect these 
user parameters, and such changes will be discussed later. 
The choice of the interaction to be the basis for 
the model can be defended in several ways. First of all, 
the interaction is an operation which is of great inter- 
est to the user. The response time of the system to a 
line of input from the user is an important parameter of 
a time-shared system. In fact, it is one of the few, well- 
defined, measurable performance parameters available. 
This response time determines the basic rate at which the 
user can operate. Moreover, data has shown that the count 
of the number of interactions per hour is a stable, relia- 
ble measure of how much the user or the system is accom- 
plishing. Counts of commands per hour are much less re- 
liable and have greater deviations from the mean. The 
fact remains, however, that users working on different 
tasks behave differently. A task is defined as the inter- 
actions comprising a sequence of commands of the same type 
from start to finish. The various purposes of the user's 
operation can be reflected by a modification of the para- 
meters of the basic interaction model. Thus, different 


interaction models can be used for different types of com-~ 
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mand sequences. In addition, information describing the 
length of command sequences in interactions per task and/ 
or commands per task is required to complete the specifi- 
cation. In this way, users can be modeled by selecting 

a task type for each, using the corresponding interaction 
model for the mumber of commands or interactions specified 
by the appropriate distribution, and then switching tasks. 
The concept of a task is useful for returning some of the 
fine structure to the operation of the interaction model 
and for deriving a new composite interaction model with 

a different "mix" of tasks. 

The expansion of the interaction model, as outlined 
above, will first involve the definition of the task types. 
The approximately 75 CTSS commands will be divided into 
five types, and then the parameters for the interaction 
model for each type will be presented and discussed. The 
first type of task is (disk) File Manipulation. In terms 
of conventional batch-processed systems, File Manipulation 
is usually carried out by hand or by tabulating equipment. 
The CTSS commands which correspond to this type of task 
print the contents of a file, combine files, split files, 
list the names of the files in a user's directory, delete 
files, copy files, etc. A complete listing of these com- 
mands is given in Appendix B. File Manipulation commands 
are characterized by usually consisting of a single inter- 
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action and requiring little processor time. 

The second type of task is that of Program Input 
and Editing. Commands of this type are used for the gen- 
eration and modification of disk files which contain the 
MAD, FAP, FORTRAN, etc. source programs written by the 
user. These commands are characterized by many interac- 
tions and very little processor time per interaction. 
Commands which generate disk files from console input for 
purposes such as memoranda, etc. are not included in 
this category. The third type of task is that of Program 
Running and Debugging. These commands cause files corres- 
ponding to binary decks to be loaded and linked by a con- 
ventional BSS loader. Also included are commands to 
start and stop these programs, to initiate debugging traces 
of their operation, to examine the registers of a program 
or the state of the processor, etc. Commands of this type 
are characterized by a moderate number of interactions 
and more processor time per interaction than any of the 
previous types. The fourth type is that of Program 
Compilation and Assembly. These commands generate binary 
deck files from the source language files, and are char- 
acterized by usually having just one interaction and re- 
quiring the most processor time per interaction. 

The fifth and final type is "Miscellaneous" and con- 
Sists of the unclassifiable commands. (Included in this 
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type are the commands which save and resume core-images 
of programs in the process of running. Also included are 
commands to generate commands, a command which will cause 
the commands listed in a disk file to be executed, the 
memoranda generating commands, etc. 

Table I presents the parameters of the various 
interaction models for each task. In addition, informa- 
tion describing the relative frequency of each type of 
task is given. This data was gathered concurrently with 


the composite interaction model statistics. 
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The shapes of the individual distributions for the 
parameters of the different tasks are very similar to 
those of the composite model. 

No data on program sizes was taken to go with Table 1, 
but it is fairly easy to estimate the program sizes of 
most of the command types. A breakdown of the usage of 
individual commands is also given in Appendix B. 

Since there are differences between the time a user 
takes to type a command, the time he takes to type a line 
of input to a program, etc., the question might be asked 
if the time in the console part of the interaction can 
be predicted from the mix of typed commands, Input Waits, 
Output Waits, etc. The answer is generally that such a 
prediction cannot be made, although the mix is some indi- 
cation. For example, it turns out that there are signi- 
ficant differences in the distributions of time in Dead 
or Dormant for File Manipulation commands and Program 
Running and Debugging commands. Perhaps the best expla- 
nation of these differences is that the user requires 
different thinking times for different command input 
lines. Some commands are easy to remember and require 
no arguments; others require a complicated argument string. 

The loss of fine structure in the operation of the 
model amounts to a smoothing of the peaks in user activity. 


Of course, using the task model will return some of this 
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structure, but the model is unlikely to reproduce every 
detail. The effects of users getting "into phase" with 
each other is still possible with the interaction models, 
but not likely. This phenomenon occurs when many users 
require service at the same time and is self-perpetuating. 
That is, as more and more users begin waiting, service 

for the individual user is reduced; and there is time for 
more users to reach the point where they require service. 
Thus, users tend to fall into step with each other; many 
working at the same time, many thinking at the same time. 
With the composite interaction model, this phenomenon will 
occur with one basic frequency. If the task model is used, 
a frequency corresponding to each task type will appear. 
In reality, there are many sub-frequencies to this rise 
and fall of the number of users in the working part of 


the interaction. 
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C. The Reliability of the Data 


During the period that this data was taken, the 
hardware configuration of CTSS remained nearly constant. 
The software system was virtually the same throughout. 
Several commands were added to the system, but their 
usage did not amount to one per cent of the interactions. 
The day-to-day user characteristics did not change very 
much. During the 47 different time periods that the data 
was taken, there were only one or two instances of really 
unusual behavior (i.e., unusually short times for the con- 
sole portion of the interaction and high processor times 
per interaction). The average of the means obtained dur- 
ing each period for the console part of the interaction 
time was 34.2 , the median was 34 , and the standard 
deviation was 5 seconds. This compares with the mean 
time for the console portion for all of the data of 35.0. 
These figures include data taken during the evening and 
on weekends: In fact, no significant differences were 
noted between the user parameters for weekend and even- 
ing operation and prime-time operation. The mean time 
for the console portion for prime-time only was 35.2 , 
for evening and weekend operation, 32 seconds. What 
makes this so surprising is that on non-prime-time the 


average number of users sharing the system was approximate- 
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ly 10, whereas for prime-time this average was nearly 
28 . Moreover, there was no measurable correlation be- 
tween the variation of the times for the console portion 
of an interaction with time, time of day, or the number 
of users interacting with the system. 

For processor time per interaction, the average of 
the 47 means was .92 , the median was .93 , and the 
standard deviation was .15 seconds. Here again, this data 
includes both prime-time and weekend and evening opera- 
tion. This compares with the overall mean of prime-time 
operation of .88 seconds of processor time per interaction 
and the non-prime-time mean of .94 . The biggest differ- 
ence between prime- and non-prime-time operation turned 
out to be in the standard deviation of the means from sep- 
arate periods. The evening and weekend user data tended 
to be much more erratic. With regard to the mix of inter- 
action types, there was no significant correlation of the 
probability of a particular type of interaction with time, 
time of day, number of users interacting with the system, 
level of service, etc. The standard deviation about the 
mean probabilities for interactions of types one through 
five were .16, .16, .28 , .31 , and .19 of the means, 
respectively. 

This data was taken by a program written to run as 


part of the CTSS Supervisory Program. The data-taking 
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program was entered each time the Scheduling Algorithm 
was entered and thus was able to determine the exact 

time of user state changes. The data gathering added 
negligibly to the overhead computations of the system 
and in no other way affected the operations of the users 
being monitored. Typically, the periods monitored amount- 
ed to several hours, but several periods were as short 

as one hour and some as long as eight hours. Due to the 
fact that there was a strict limit on the size of the 
data-gathering program, some important parameters could 
not be measured. This is the primary reason why the pro- 
gram size distribution was gathered during a separate 
interval. 

Overhead computation can be thought of as degrading 
the effective operating rate of the processor as seen by 
the user. Overhead computation primarily involves sche- 
duling and the processing of input characters from the 
remote consoles. Every 200 milliseconds, the processor 
is stopped and control is transferred to the CTSS Super- 
visory Program for these purposes. Therefore, this over- 
head can be considered as being uniformly distributed 
since users are generally interrupted for these functions 
many times. Rough measurements show that CTSS, operating 
with 30 users, has an approximate overhead of five per 


cent. That is, a program requiring one second of IBM 7094 
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processor time under non-time-shared operation, requires 
approximately 1.05 seconds on CTSS. As previously stated, 
all processor time measurements include this overhead. 

Also included is user programs' use of the disk (not to 

be confused with loading commands from the disk) as a 
tape-like, input-output device. Data taken over the summer 
of 1964 by T. Hastings, formerly of the M.I.T. Computa- 
tion Center Programming Staff, indicates that the average 
program accesses (i.e., reads or writes) approximately 


1500 disk words per interaction. 
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D. Changes in the System Reflected by User Characteristics 


en et a 


Changes in the time-shared system itself certainly 
have an effect on the behavior of the users. For example, 
if a heavy scheduling penalty is placed on the users of 
large programs, the average program size will decrease. 

In fact, over the summer of 1964, data taken by Hastings 
indicated that the average program size dropped from 
9,000. to 6,000 words in the space of three months be- 
cause of just such a scheduling policy. The addition of 
new commands, which may supplant older ones but operate 
in a different manner, will obviously affect the users 


characteristics. 


31. 


III. MODELING TIME-~SHARED SYSTEM HARDWARE AND SOFTWARE 


This section describes models which represent time- 
shared hardware-software systems. The models will range 
in generality from CTSS-like systems up to idealized, 
‘multiple-processor, time-shared systems. Simulation 
models which represent systems close to CTSS will be used 
to predict distributions for response times, processor 
usage, disk usage, saturation, etc., whereas more general, 
mathematical models will be used for the prediction of 
the mean values for some of these parameters. The level 
of detail incorporated into these models will match that 
of the interaction model. That is, individual instructions, 
data words, and disk tracks will not be considered. The 
models will be based on processor time for an interaction, 
transmission time for a block of words from disk to core- 
memory, etc. 

The first model developed matches CTSS. The very 
same Scheduling Algorithm and storage allocation scheme 
will be used. Next, a simple, first-come, first-served, 
round-robin scheduling procedure will be substituted. 
Then, a model which incorporates multi-programming tech- 
niques with the CTSS hardware configuration will be devel- 
oped. Finally, a simple continuous-time Markov model will 
be used to represent both single-processor and multiple- 


processor time-shared systems. 
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As was stated in the Introduction, the first three 
models to be developed are of the simulation type. Simu- 
lation models are required because the level of detail 
necessary to handle some of the features studied is beyond 
the scope of mathematically tractable models. Markov 
models cannot, in general, be used to represent processes 
where other than random queueing is used. Queueing Theory 
models are not usable for processes where the arrival 
rates of service requests are a function of the service 
rate. Furthermore, the addition of pre-emptive scheduling 
complicates the mathematics beyong the point where models 
can even be formulated. 

In order that efficient simulations can be written 
using a convenient notation, a special simulation pro- 
gramming language and operating system were designed. The 
language itself is fairly straightforward and about as 
readable as any of the algebraic programming languages. 

A discussion of the problem will be found later in this 
section, and a complete description of this simulation 
language and operating system will be found in Appendix C 
along with listing of the simulation programs for the 


models presented here. 


336 
A. The CTSS Model 


The CTSS hardware-software simulation model consists 


of six interacting sub-programs. These are: 


(1) The actual CTSS Scheduling Algorithm (see 
Appendix A). 


(2) The Console element which simulates the users! 
finishing the console portion of the interaction, 
waiting for the completion of the working part, 
etc. This element is based on the data taken in 


Section II for the composite interaction model. 


(3) The Main Control element which informs the 
Scheduling Algorithm of changes in user status, 
starts and stops the processor, initiates swapp- 
ing. It does the former at the direction of 
the user element, the latter two at the direction 


of the Scheduling Algorithm. 


(4) The Storage Allocation element which directs 
the detailed operation of swapping. It controls 
the disk and drum storage elements, causing pro- 
grams to be loaded and dumped in accordance with 


the “onion skin algorithm" used in CTSS. 


(5) The Processor element which is started and stopped 
by the Main Control element. 
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(6) The Bulk Storage element which simulates both 
drum and disk storage, controlled by the 


Storage Allocation element. 


The user-simulating element is based on the composite 
interaction model developed in Section II. An array of 
values indicating the status of each user is kept. When 
a user first enters the console part of an interaction, 
the amount of time he will "think" is drawn from a distri- 
pution fitting the one in Figure 1. After this time elapses, 
a signal is sent to the Main Control element placing the 
user into the Working status. When a "finish" signal is 
received from the Main Control element, the process is 
repeated. 

The Main Control element has several functions: 

(1) to enter the Scheduling Algorithm every 200 milli- 
seconds for the basic timing event, (2) to inform the 
Scheduling Algorithm of user status changes using the six 
CTSS user states, (3) to control the starting and stopping 
of the processor and the swapping process under the direc- 
tion of the Scheduling Algorithm. An informal flow chart 
of this element is shown in Figure 5. Using the distribu- 
tions presented in Section II,the Main Control element 
selects a program size and internal state for the user in 
the console portion of an interaction. Likewise, when a 


user enters the Working portion of an interaction, a program 
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Figure 5 : OPERATION OF THE MAIN 
CONTROL ELEMENT FOR 
THE CTSS SIMULATION, 
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size and processor time are selected. 
The Storage Allocation element is activated whenever 
@ swap is to occur. Given the size and identification 
of the program to be loaded and a "map" of the current 
contents of the core memory, this element causes the pro- 
per disk and drum activity to load this program. Using 
the CTSS "onion skin algorithm", only as much of the con- 
tents of the core memory is dumped as is required to 
make room for the incoming program. All dumping is done 
with the drum. Since all programs are loaded from loca- 
tion zero, there can be only one complete program in core 
at a time. However, there also may be many partial sec- 
tions of other programs in core. In CTSS, the number of 
these partially-dumped programs is limited to four. Natur- 
ally, whenever a program is loaded which is already partially 
in core, only the part that is missing is transmitted from 
the drum. In addition to the transmission of the actual 
programs, each swap is accompanied by the dumping and load- 
ing (with the drum) of the processor status and disk file 
status of the outgoing and incoming programs. This trans- 
mission consists of approximately 500 words in each direction. 
The Processor element is started by being given the 
number of instructions to be executed. If it is stopped, 
it supplies the number of instructions actually executed. 


If it finishes, it informs the Main Control element. The 
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Bulk Storage element simulates the disk and drum systems. 
The number of words to be transmitted is supplied along 
with the type of unit (disk or drum), and the element 
signals when the transmission is completed. For the 
drum, a rotational delay uniformly distributed between 
zero and 17.2 milliseconds is used with a transmission 
time of 8.4 microseconds per word (IBM 7320A amin The 
disk is simulated as having a head positioning delay of 
either 50, 120 , or 180 milliseconds with probabilities of 
-033 , .134 , and .833 respectively. The rotational delay 
is distributed uniformly between zero and 34 milliseconds, 
and the transmission time is 66.6 microseconds per word. 
Since up to 9320 (20 "tracks") words may be read without 
repositioning the read/write heads of the disk, some assump- 
tion must be made about the organization of the programs 
on the disk. Data has shown that approximately 80 per cent 
of the programs loaded from the disk come from files which 
are arranged optimally on the disk, i.e., on adjacent 
tracks. The remainder of these files come from the user's 
file area (i.e., they are RESUME class programs, see 
Appendix B) and were determined to be arranged less op- 
timally, approximately 650 words being obtained per seek. 
The interconnection of these elements is shown in 


Figure 6. Since CTSS does not overlap the operation of 
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Figure 6 ; INTERCONNECTION OF ELEMENTS IN CTSS SIMULATION 


(Dotted lines show connections for overlapped 
use of processor and disk or drum.) 
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the drum, disk, and processor, there is no interference 
at the core memory for accesses. Thus, there is no need 


to represent the core memory in the CTSS simulation. 
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B. Variations of the CTSS Model 


ee ee 


The first variation to be considered is a change 
in the Scheduling Algorithm. Instead of the miltiple- 
queue arrangement used by CTSS, a simple, first-come, 
first-served, round-robin procedure will be used. The 
time interval during which users! programs are given 
"pursts" of processor time will be a constant and not 
variable as in CTSS. The length of the burst will also 
be referred to as the "quantum time". In operation, a 
list of all of the users in the working state will be 
kept, and programs will be given bursts of processor 
time in the order that they are in this list. As users' 
programs finish, they are removed from the list; users 
whose programs have just received a burst of processor 
time are removed from the front and placed at the end of 
this list. In both cases, the remaining programs are 
moved toward the front. Programs newly entering the work- 
ing status are added to the end. 

The final model to be simulated will represent a 
system in which swapping and processor operation are 
overlapped. While a program is being run by the processor, 
the program which was running previously is dumped and 
the next program to run is loaded. Since loading and dump- 
ing cannot occur simultaneously, there must be room in 


the core memory for at least two complete user programs-- 
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the program being executed and the program being dumped 

or loaded. Should two programs intended to run in sequence 
not fit together in the core memory, the processor must 

be stopped to complete the swapping. This procedure is 
shown in detail in the informal flow chart of Figure 7. 
While a program is running, all or as much as will fit of 
the next program to run is loaded. After the quantum time 
(two seconds) is up, the swap is completed if the next 
program could not be completely loaded; and then this pro- 
gram is started. A dump of the stopped program is then 
begun, and the process is repeated. Scheduling is done 
strictly on the basis of program size, with a simple algor- 
ithm used to sort programs in an attempt to maximize the 
number of adjacent programs fitting together in memory. 

A model in which all disk operation (including its 
use by user programs as an I/O device) is overlapped with 
processor operation is being undertaken by Mr. Donald 
Widrig of the staff of Project MAC. His simulation will 
use the same user model and simulation system developed 
and used here. A more detailed study of bulk storage device 
operation in a multi-programmed system is being carried 
out by Mr. Peter J. Denning, also of the staff of Project 
MAC,as an S.M. thesis. The results of both these studies 


will not be available intime to be discussed in this report. 
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Cc. The Need for a New Simlation System 


There exist dozens of different types of simulation 
programming systems. Among these are many special-purpose 
as well as several general-purpose systems. At this time, 
there exists no special-purpose simulation programming 
language specifically for use with models of digital 
computer systems. The general-purpose languages, such 
as SIMSCRIPT, GPSS, etc., all have faults which render 
them unsuitable for this type of work. Since SIMSCRIPT 
(MARKOWITZ, 1963) and GPSS (IBM, 1963) are perhaps the 
most widely used of the general-purpose languages, they 
will be discussed in more detail. The basic objections 
to these languages are that: (1) their notation is not 
convenient for the description of digital systems, (2) 
they are inefficient in their use of computer time, and 
(3) their basic timing structure is not well matched to 
the structure of the digital systems being simulated. 

SIMSCRIPT is an event-based language. That is, the 
simulation is described, event by event, with small pro- 
grams, one per event. Each event program (or sub-program) 
must specify the times for the events following it. Con- 
ditional scheduling of an event is extremely difficult. 
The notation is an augmented version cf FORTRAN, which 
is acceptable; but this organization does not take advantage 


of the modularity of digital systems. SIMSCRIPT's list 
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of coming events may grow to an indeterminately large 
size, but in a computer system there are only as many 
coming events as there are independent elements. In 
SIMSCRIPT it is difficult to distinguish the events 
associated with a particular physical element. Thus, 

the modification of such an element is frequently not 
easily accomplished. Finally, SIMSCRIPT is very diffi- 
cult to learn, there are no real provisions for automatic 
tracing and other debugging aids, it is inefficient, and 
it is not available for on-line use with CTSS. 

On the other hand, GPSS is organized around the 
flow of information through a system. A fairly incon- 
veniént block diagram notation is used. Again, it is 
difficult to express and take advantage of modularity 
in GPSS. It is also extremely inefficient from the 
standpoint of computer time because it is executed inter- 
pretively, not compiled into machine language. The use 
of canned, machine language routines is, therefore, 
difficult. It is available as a command with CTSS, but 
is rarely used, despite the fact that quite a lot of sim- 
ulation is being done at Project MAC. Furthermore, GPSS 
is difficult to learn. 

As opposed to the above disadvantages, the simula- 
tion programming system used here and described in detail 


in Appendix C is easy to learn, has great modularity, has 
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automatic debugging features, is moderately efficient, 
and, it is felt, is very well suited to the simulation 
of digital computer systems. This new language is now 
being used by several people at Project MAC who learned 
it in approximately two or three hours of instruction. 
The language is based on MAD, and each physical element 
in a system to be simulated corresponds to a conventional 
MAD subroutine. Built-in traces of the activities of a 
running simulation can be started or stopped at any time 
by the programmer, special post-mortems are available 
which print the state of the simulation at any point, 
and real-time interaction with the simulation from a 


CTSS remote console is possible. 
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D. Continuous-Time Markov Model for CTSS-like Systems 


i 


A simple continuous-time Markov process will be used 
to represent the operation of a single processor, time- 
shared system. The primary reasons for developing such 
a model are to compare its predictions with those of the 
simulation models and with the actual CTSS data and to 
extend its usage to more complex systems. The basis for 
this model is the interaction model for the CTSS user, 
described in Section II. The states of the Markov pro- 
eess representing a system with n users will correspond 
to the number of users in the working part of the inter- 
action. That is, state j being occupied will indicate 
that j users are in the working portion of an interaction. 
Thus, the Markov process will have (n+1) states. In 
order to use a continuous-time Markov process, the distri- 
butions of processor time per interaction and the duration 
of the console portion of the interaction must be exponen- 
tial. The mean time for the console portion will be T ; 
the mean processor time per interaction, P . In this 
development, P will include the necessary swap time per 
interaction since in CTSS swapping is not overlapped with 
computation, and the processor stands idle while swapping 
occurs. The time-shared aspect of the operation of CTSS 
will be idealized in that no overhead will be associated 


with additional users waiting for service. The processor 
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will be considered as switching from program to program 
at an infinite rate with no loss of efficiency. Thus if 
there are currently j users waiting for service (i.e., 
in the working part of an interaction), the rate of exit 
to the state where (j+1) users are waiting for service 
is (By) 3; that is, (n-j) users are in the console por- 
tion of the interaction. The rate of exit to the state 
where there are (j-1) users is () - This implies that 
each of the j users is receiving (3) of the processor's 
capacity. That is, each user is finishing at a rate of 
(Fp) and any one of the j users is finishing at a rate 
of (5). The rate matrix (HOWARD, 1960, p. 92 ff.) A, 
is shown below. An expression for the steady-state 
probabilities is found; expressions for the average number 
of users waiting for service and the mean ratio of waiting 


time to processor time are derived. 
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The equations for the 7's are: 
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TM is the steady-state probability thatthe processor 
is idle. 
Now, let W be equal to the mean length of time 


@ user spends in the working part of the interaction 
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(i.e., the mean response time). Let @ be the average 


number of users waiting for service. Then 
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Dividing both sides by P and using the definition of r: 
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It is interesting to note that the rate matrix 

and the resulting calculations would be the same if it 

were assumed that each program were run a finite quantum 

of time or if all programs were run to completion, i.e., 

batch processed) This is due to the fact that there is 

no swapping loss and that the time distributions are 

exponential. Use of other types of distribution func- 


tions would not, in general, yield the same results for 


any quantum size. 
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E. Markov Model for Multiple-Processor, Time-Shared Systems 


Using the same definitions and assumptions as for 
the single-processor system, a model for the operation 
of an m processor, n user time-shared system can be 
derived. From a state where j users are waiting for 
service, the exit rate to the state where there are (j+1) 
users waiting for service is (Pre) » the same as for the 
Single processor model. If j is less than m, then 
each user's program is assigned its own processor and the 
rate of exit to the state where (j-1) users are waiting 
for service is (2) . If gj is greater than or equal to 
m, the j users share the m processors just as in 
the case of a single processor, and the rate of exit to 
the state where (j-1) users are waiting is (5) » The 
rate matrix for this process is not shown since it is similar 
to the one for the single processor case. Solving the 


equation 


TTA = 0, 


the steady-state probabilities are obtained: 
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The average number of processors is similar to @ and 
m 


is equal to d. (m-1) ™, . The expression for the ratio 
{= 
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of the average time in the working part of the interac- 


tion to the average processor time per interaction is: 
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The results obtainable from the models presented 
in this section will be compared to the measurements 
made on CTSS in the next section. No closed form 
expression for a in terms of T was found. However, 
as n_ gets large, "6 approaches zero, and 
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IV. ANALYSIS OF MODEL PREDICTIONS 


This section compares the results obtained from 
the various simulation models, the Markov models, and 
the CTSS data. In addition, extensions into multiple- 
processor systems are analyzed. Each system studied is 
compared on the basis of several metrics. Measures of 
@ system's response time to requests for service, hard- 
ware efficiency, scheduling procedure, and the effects 
of loading will be used to illustrate the differences 
between time-shared systems. Since the Markov model 
for the single-processor, time-shared system yields very 
accurate results, this model and its m1ltiple-processor 
extension will be used in the discussion of both parallel 
and series connected multiple systems composed of either 
equal general-purpose processors or special-purpose 
processors. This section can be divided into two portions: 
a detailed study of CISS and related systems, and a general 
discussion of multiple-processor, time-shared systems. 
Four measures are used to compare the results from 
the CTSS-like systems. The first of these is the depen- 
dence of the mean time for the working portion of the 
interaction (i.e., response time) on the average number 
of users interacting with the system, all other para- 


meters being equal. Since during the measurements of CTSS 
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in operation these other parameters could not be con- 
trolled, the variation of processor time per interaction 
will be removed by including it in the measure of re- 
sponse time. Therefore, the ratio of response time to 
processor time per interaction will be substituted for 
response time. It turns out that this ratio is a more 
stable measure of CTSS performance. The variation of 
this ratio as a function of the average number of inter- 
acting users is a measure of how well the system responds 
to a change in its load. 

Secondly, the relationship between processor time per 
interaction and response time will be investigated. This 
will be done with no variation in the number of interact- 
ing users, the distribution of processor time per inter- 
action, program size, etc. This relationship is a measure 
of the scheduling policy of a system. For example, how 
@ system achieves a low mean response time by more favor- 
ably scheduling short running jobs can be clearly seen. 
Third, the probability densities of the response time for 
the various systems will be discussed in conjunction with 
the scheduling policies. 

Finally, the percentage usage of the processor, disk 
memory, and drum memory will be plotted as a function of 
the number of users interacting with the system. This 


pilot is used in a discussion of the relationships between 
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hardware usage and scheduling policy, response time, etc. 

Throughout the use of the above measures, the results 
from the simulation. of CTSS will be compared with the 
actual measured data. In some cases, no CTSS data could 
be measured. Since the primary objective in the CTSS measure- 
ments was to characterize the user, and since time and 
space for the measuring prourene was limited, some para- 
meters were not measured. 

The results from approximately twenty simulations are 
used here. Each simulation represents the operation of 
a time-shared system under a load of between twenty and 
forty-five users for a period of eight hours. Each such 
simulation cost between ten and twenty minutes. of IBM 7094 
computer time. While such a cost is not exorbitant, it 
certainly put a limit on the total rumber of simulations 
which could be run, and thus there were certain simulations 
which could not be run. 

Multiple systems are divided into two types: series 
and parallel. The parallel systems are those in which 
interactions may be processed by any one of the several 
processors in the system. The selection of which processor 
is to service a particular user's interaction depends on 
the decision process employed. Serial systems are those 
in which interactions must be processed by more than one 


processor in some sequence. Both types of systems will be 
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considered for the two-processor case. The results are 
easily generalizable to cases with more than two processors 
and having any arrangement of interconnections. 

Two types of parallel two-processor systems are dis- 
cussed. First, a system in which either processor may 
serve any portion of any user's interaction requirement 
is analyzed. This system corresponds exactly to the case 
for m equal to two of the multiple-processor Markov 
model derived in Section III. This system can be thought 
of as a single queue feeding two processors. The second 
type of system analyzed is one in which the two processors 
are able to service mutually exclusive types of interac- 
tions. That is, each processor has its own queue. In 
both cases, the two processors have the same capacity and 
service the same number of users, on the average. This 
is an optimal arrangement, and the effect of a non-optimal 
situation is discussed in another example. A double-speed, 
single-processor system will be used for a basis of com- 
parison with these parallel two-processor systems. A 


two-processor serial system is then discussed and analyzed. 
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A. Response Time vs. the Number of Users 


Se 


Figure 8 shows the ratio of mean response time (time 
for the working portion of an interaction) to mean pro- 
cessor time per interaction for various systems. The 
normalization of response time with respect to average 
processor time is unnecessary for the simulated systems 
because the mean processor time per interaction was identi- 
cal for all. However, the CTSS data was taken under normal 
operating conditions, and thus the data points represent 
many different means for processor time per interaction. 
Even though these means were all close to the overall mean 
of .88 seconds, using the ratio of response time to pro- 
cessor time gives less variance to the results than just 
the raw response time. The CTSS data points shown in 
Figure 8 were measured during all periods of operation-- 
prime-time, weekends, and evenings. Through these points 
is passed a cubic, least-squared error fit. The RMS 
deviation from this fit was a surprisingly low 1.2. 

The data points resulting from the simulations of 
CTSS are also shown in Figure 8. All of the simulation 
data points are well within the envelope of the CTSS points 
and are close to the cubic fit. 

The prediction of the single-processor Markov model 


is also shown in Figure 8. In order to use this model, 
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RATIO OF TIME FOR WORKING 
PART OF INTERACTION TO MEAN / 
PROCESSOR TIME PER INTERACTION 


IS 


A-A MARKov Move PREDICTIONS 


B-BsFiT To crss DATA 


—PoInTs- 
CRMS DEVIATION =1.2) for 


°«-CTss OATA 
O-CTSS SIMULATION 


B- AOUN0-ROGIN, 
FIRST-COME, PURST- 
Seaveo, 


M- OVERLAPPED 
SWAPPUE, 


to is ° 2s ° 4d 4 
MEAN NUMBER OF INTERACTING users > ae ad 


RATIO OF MEAN TIME FOR WORKING PORTION OF INTERACTION CRESPONSE TIME) 
TO MEAN PROCESSOR TIME PER INTERACTION VS. MEAN NUMBER OF INTERACTING 


USERS, 


*09 


61. 


the mean processor time per interaction must be increased 
to take into account the mean swapping time per interaction 
because the processor is idle during swapping in CTSS. The 
mean swapping time per interaction was measured and found 
to be .56 seconds. Thus, the mean net processor time per 
interaction is 1.44 seconds. A mean time for the console 
portion of an interaction of 35.2 seconds was used. These 
values were substituted into the expression for ) for 
the single-processor Markov model in the last section. 

The results obtained from this expression must be increased 
by a factor equal to the mean processor time per inter- 
action, including swapping, divided by the mean processor 
time per interaction without including swapping time. This 
is done to keep the ratio in terms of the .88 second pro- 
cessor time per interaction. The implications of the good 
fit of the results obtained from the Markov model to the 
CTSS data will be discussed in the conclusions. No sig- 
nificance should be attached to the way the Markov curve 
crosses the fit to the CTSS data. 

Also shown in Figure 8 is the data obtained from the 
simulation of CTSS with its scheduling algorithm replaced 
by a first-come, first-served, round-robin scheduler. 

Each user's program was allowed to run for at most two 


seconds. If it had not finished by that time, it was pre- 
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empted and placed at the end of the queue, and the next 
user swapped in and run. The slightly worse performance 
of this system compared to CTSS can be attributed strictly 
to the difference in scheduling. The difference between 
this system and that of the Markov model can be attributed 
to the fact that they have slightly different swapping 
overheads. 

The overlapped swapping and processing simulation 
model's results are also shown in Figure 8. The reason 
for the improvement in performance is that the time that 
the processor is idle because of swapping is down to .33 
seconds per interaction, a decrease of approximately 
41 per cent from the CTSS value. 

The ratio of response time to processor time can be 
thought of as indicating what part of the system's capa- 
city a user is receiving. For example, a value of ten 
for this ratio indicates that, on the average, a user re- 
ceives one tenth the capacity of the system. As expected, 
this ratio is just over one for only a few interacting 
users and nearly equal to n , the number of users, as n 
gets large. The increase over a unity value for n equal 
to one or two is due to swapping time. As n increases, 
this ratio increases slowly due to the fact that not all 


interacting users require service at once. For large n, 


nearly all of the users are in the working portion of 


the interaction and the ratio approaches n. 
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B. Scheduling Policy and Response Time Distributions 


The average response time to a particular processor 
time requirement can be a useful parameter. It is used 
here to show how the CTSS Scheduling Policy differs from 
the round-robin,first-served system. These measurements, 
made from simulations and shown for a load of twenty-five 
interacting users in Figure 9, is highly dependent on 
the distribution of processor time per interaction, and 
the one used to obtain these measurements was shown in 
Figure 4 in Section II. It is clear that CTSS obtains its 
slightly better mean response time by favoring the short- 
running interactions at the expense of the long ones. The 
‘primary effect is that the swapping overhead is reduced. 
The reason for this effect is that the longer-running 
interactions, with low priority, are run for a longer time 
when they are finally run. This is one of the advantages 
of a dynamically variable quantum time. The "shortest- 
operation-first" aspect of CTSS scheduling seems to be 
Slight, and is discussed in the conclusions. 

Figure 10 shows the response time versus processor 
time per interaction for CTSS under varying loads. The 
shift from an effective quantum time of two seconds to 
one second can be clearly seen at loads. of approximately 


28 users. Figure 11 shows the same curves for the round- 
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Figure 11 : MEAN RESPONSE TIME VS. PROCESSOR TIME PER INTERACTION FOR VARIOUS QUANTA 
IN ROUND-ROBIN, FIRST-COME, FIRST-SERVED SCHEDULING. ¢ 25 USERS ) 


robin, first-served scheduler for 25 users and values 

of quantum times from .5 to ten seconds. Using a 
quantum time of ten seconds is almost equivalent to a 
policy of running all programs to completion. The 
variability of the response times about the means plotted 
can be estimated by the jaggedness of the plots. From 
this it could be deduced that the CTSS scheduling algorithm 
yields somewhat less predictable response times than 

does a round-robin, first-come, first-served scheduler. 
This is in agreement with the result of job-shop schedul- 
ing showing that first-come, first-served scheduling 
yields higher a mean completion time with a lower variance 
than shortest-operation-first scheduling, (see CONWAY, 
1964, p. 102). This "trade-off" will be discussed in the 
conclusions. 

There are several restrictions on the response time 
as a function of processor time. If the scheduling 
procedure does not schedule on the basis of job types 
or attempt to predict the processor time for an interac- 
tion, the slope of the response time versus processor 
time curve must be greater than or equal to unity at all 
points. Furthermore, the response time as a function of 
the processor time, w(p) , mist satisfy the following 


relation: 
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a(p) 
nf Paley si. 


6) 

where n is the number of users interacting with the 
system, p is the processor time per interaction, a(p) 
is the probability density of p, t(p) is the think time 
as a function of p , and w(p) is the scheduling policy 
function-- the response time as a function of p. All 
that this relationship expresses is that the scheduling 
policy cannot attempt to provide more than one second of 
processor time per second to the users. 

Figure 12 shows the response time distributions for 
CTSS (simulation) and round-robin scheduling with quanta 
of .5 and two seconds. Unfortunately there is not 
enough room on the graph to show the differences between 
CTSS and the round-robin schedulers for large response 
times. The CTSS response time distribution has by far 
the longest tail. The effects of CTSS favoring the short- 
er interactions is evident again in the higher probability 
for shorter response times. The round-robin with a quantum 
time of two seconds yields almost exactly the same distri- 
bution as for longer quanta, except for differences in 
means. An interesting effect can be seen upon comparing 
the distributions for the two different round-robin schedulers. 
With a quantum time of .5 seconds, it would be expected 


that the probability of extremely short response times 
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should increase over the case with a quantum of two seconds. 
However, the effect is that a .5 second quantum increases 
swapping overhead sufficiently to overcome most of the 
advantage of a small quantum time to short running users. 
The data points from the CTSS measurements are not shown 
in Figure 12 because they coincide almost exactly with 
the results of the CTSS simulation. 

As a further means of comparison, the mean response 
times of the various systems simulated are listed below 


(all figures are for 25 users): 


System Mean Response Time (seconds) 


CTSS 7.0 
Round-Robin 

Quantum = 25 10.7 

Quantum = 1.0 Tel 

Quantum = 2.0 723 

Quantum = 10.0 8.1 


Overlapped Swapping 1 
version of CTSS De 


The differences in the mean response times for the round- 
robin schedulers are due to the differences in swapping 
overhead. Other effects of changing the quantum size are 


discussed in the conclusions. 
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C. Hardware Usage 


Figure 13 shows the percentage usage of the processor 
for users' program execution as a function of the number 
of interacting users. Shown are the CTSS data points as 
well as the points from the simulations of CTSS, the 
round-robin system with a quantum time of two seconds, 
and the system with overlapped swapping. The phenomenon 
of saturation can be clearly seen. As the number of users 
increases, the usage of the processor increases until some 
limit is reached. With completely overlapped swapping, 
this limit would be 100 per cent. But since there is some 
Swapping overhead, the limit is approximately 60 per cent 
for CTSS and the round-robin system and 75 per cent for 
the (imperfectly) overlapped system. It is interesting 
to note that these curves are equal to the quantity” (1-7) 
of the Markov models within a multiplicative constant, 
where Ce is the steady-state probability of zero users 
waiting for service, and the constant is equal to the 
asymptote of the usage curves. (The Markov model predic- 
tions are not plotted since they are so close to the measur- 
ed results. ) 

Since saturation can be identified with the probability 
of zero users waiting for service, it will be defined as 
follows: saturation occurs when the probability of zero 


users waiting for service is lower than some small number , € . 
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The specification of & is arbitrary, but typically 
might be .O1. 

Figure 14 shows the usage of the drum and disk for 
swapping as percentage of total time. As is expected, 
the usage of the disk and drum increases with the number 
of interacting users. The usage of the disk for CTSS 
is slightly larger than that of the round-robin. This 
effect is a result of the preference shown by the CTSS 
Scheduling Algorithm for short-running interaction. This 
preference extends to interactions which have received 
no service; and since these interactions very often re- 
quired loading from the disk, the amount of disk usage 
is up slightly. The drop in disk usage for CTSS at 
approximately 30 users is due to the fact that the CTSS 
scheduler switches to an effective quantum time of one 
second at that point (see Figure 10). With a smaller 
quantum time, there is more swapping and thus an increase 
in the use of the drum. Comparing the CTSS disk and drum 
usage with that of the round-robin scheduling (quantum 
time is two seconds), it is apparent that CTSS has a 
slightly lower swapping overhead. This is due to the 
fact that the CTSS Scheduling Algorithm uses different 
quanta depending on the number of users waiting for ser- 
vice at a particular time-- the fewer the users waiting, 
the longer the effective quantum. 

The approximately 10 per cent usage of the drum and 
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and 30 per cent usage of the disk implies that, if inter- 
processor interference could be eliminated, a single disk 
or drum could service more than one processor. The only 
condition on this statement is that the storage capacity 
of the disk or drum would have to be increased to take 
care of the additional users' disk files or core-images. 

In the system with overlapped swapping and processor 
use, the total use of the bulk storage devices increases 
with the usage of the processor, as is the case with the 
unoverlapped systems. At a load of 45 interacting users, 
the usage of the drum was 12.7 per cent, of the disk, 

33.8 per cent. Unoverlapped usage of the drum amounted 

to 8.5 per cent, of the disk, 9.1 per cent. Unfortunately, 
runs were not made with more users, and saturation opera- 
tion with the overlapped system was not achieved. However, 
an extrapolation of the measurements taken indicates a 
saturation level of usage for the processor at approximately 


75 per cent. 
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D. Multiple Systems 


Parallel miltiple-processor systems can be divided 
into two basic classes depending on the ability of a 
single processor in the system to serve requests. Ina 
multiple system with general-purpose processors, any 
processor can service any request. In effect, requests 
to be serviced (i.e., programs to be executed) are drawn 
from a single queue. The alternative multiple-system 
arrangement uses special-purpose processors to the extent 
that a single processor can serve only certain types of 
requests. In this case, a processor draws requests to 
be serviced from the queve containing the proper type 
of request. In practice, a multiple system may contain 
both types of operation: a group of processors fed from 
a single queue, and many queves differentiated by the type 
of request being serviced by the attached processor group. 
The third kind of multiple system is the serial type in 
which jobs must pass through two or more time-shared pro- 
cessors in sequence. An example of such a system would 
be one with input and output processors which pre- and 
post-process all jobs for the main processor. 

In general, any multiple system can be analyzed by 
considering each group of processors individually, as will 


be discussed. Two parallel multiple systems, each with 
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two processors, will be analyzed. Their performance will 
be compared to a single-processor system of the same 
capacity in total instructions executable per unit time. 
Next, a study of the effects of augmenting a CTSS-like 
system with a processor capable of simple character manip- 
ulation and channel operations to take care of some of 
the job types normally executed at the central processor. 
The augmented system will be compared to CTSS on the basis 
of performance and additional cost. Finally, serial mul- 


tiple systems will be analyzed. 


196 
1. Equal Capacity, Parallel Multiple Systems 


The first mltiple system to be considered is one 
with two general-purpose processors. Assume that each 
processor has the capacity of the single processor of 
the CTSS system (IBM 7094-I) and that the same swapping 
overhead is present. Thus, the average net processor 
time per interaction is 1.44 seconds, .88 seconds of use- 
ful processor time and .56 seconds of processor idie 
time due to swapping per interaction. With an average 
"think" time of 35.2 seconds, the parameter r is .O41. 
The results from the Markov model of a two-processor, 
time-shared system are plotted in Figure 15. The average 
waiting time (time in the working portion of an interac- 
tion) is shown as a function of the number of users inter- 
acting with the system. 

A system with two special-purpose processors can be 
equivalent to two separate time-shared systems if each 
sub-system is used, on the average, by half of the user 
population and each is equally loaded (i.e., equal P's 
and T's ). As will be seen, this is an optimal situa- 
tion. Any deviation from the ideal results in an increas- 
ed overall mean response time. For such a system, the 
mean response time can be calculated as a function of n, 
the number of interacting users, by using 5 in the 


expression for the response time for the single-processor 
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Markov model. The results of this calculation are also 
shown in Figure 15. 

As a basis for comparison, a single-processor system 
of exactly the same capacity as the two-processor systems 
will be used. If the single-processor system is exactly 
twice as fast for every operation, the r for this system 
is .02 , exactly half that of the duplex systems. The 
mean response time for this system is plotted in Figure 15 
as a function of the number of interacting users. 

Looking at the three systems from the standpoint of 
overall mean response time, the double-speed, single-pro- 
cessor system is superior. The two processor, single-~queue 
system is better than the two-processor, two-queue system. 
The reasons for the differences in the systems can be ex- 
plained in terms of their degrees of freedom. The single- 
processor system can turn the entire capacity of its pro- 
cessor to the execution of a single job. Thus, the single- 
processor system is superior by almost a factor of two to 
the two-processor systems when the number of users is small. 
The only difference between the two-processor, single-queue 
system and the single-processor system is their performance 
when only one user is waiting for service. The difference 
between the two-processor, two-queue system and the two- 
processor, single-queue system is accountable to the fact 


that there are times when the queue of one processor of the 
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double-queue system is idle, and its capacity cannot be 
used to relieve the other processor. The fact that the 
plots all join into the same straight line is indicative 
of the fact that all three systems have identical capacity. 
The full capacity of all three systems is used because the 
number of interacting users is sufficient to keep all of 
the queues non-empty nearly all of the time. Thus, running 
in complete saturation, the performance of each of these 


systems is identical. 
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2. "Polymorphic" Systems 


The two-processor, two-queue system is of special 
interest because it can be used to represent a system with 
two special-purpose processors. In such a system, the 
users interact with one processor at a time, and the pro- 
cessor that is used is determined by the type of task the 
interaction performs. The assumption will be made that 
the mix of interaction types remains constant regardless 
of the service a user receives. Thus, the relative proba- 
bilities of different types of interactions remains fixed. 
Reference should be made to the end of Section II for the 
measurements made of the probabilities of different types 
of interactions. In order to quantitatively analyze the 
two-queue, two-processor situation, the following variables 
are defined: 


a = the probability that a user's next iner- 


i 
action will require the use of processor 
The sum of the a's is unity. 

Py = the mean processor time per interaction 
for processor i. This time includes 
any non-overlapped swapping time. 

T, = the mean time for the console portion of 
interactions using processor i (i.e., 
"think" time). 

n = the total number of users interacting with 


all processors. 


i 
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All of the above parameters are determined by user 
behavior and the speeds of the various processors. The 
following variables are functions of the above: 

n, = the mean number of users interacting 
with processor i. 

W, = the mean time for the working portion of 
interactions using processor i (i.e., 
response time). 

W = the overall mean response time. 

The analysis of multiple, special-purpose processor 
systems will be carried out for only two processors, but 
the extension to any number is straightforward. In order 


to determine the W and W, the ny must be found. 


i 
For a two-processor system, Nj =n-ny, and thus only 


n, need be found. The expression for ny 


1 
ite a,(W,+T,) a 
“= 3 
1 a, (W347, ) + a5 (W5tT5) 

was found by equalizing the rate of users starting inter- 
actions of type one and the rate of users finishing inter- 
actions of type 1. This equation can also be interpreted 
as the total number of users multiplied by the mean propor- 
tion of the time that a single user is interacting with 
processor number 1. Since the Wy are non-linear func- 


tions of the ny» and since both are unknown, the n, are 


perhaps best found by a relaxation technique (i.e., a value 
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is assumed for Ni » Ny s Wy » and Wo are calculated; a 


new value for n is calculated, etc., etc.). This being 


1 
done, the overall mean response time per interaction can 


be found: 


In the two multiple systems previously discussed, the 
two-processor, two-queve system was "balanced". That is, 
each processor served the same average number of users, 
each had the same associated mean think and processor time 
per interaction. In general, values for the parameters of 
a system with special-purpose processor will not be so 
favorable. The parameters under the control of the systems 


designer are the P and the Oss Selectively scheduling 


a: 
on the basis of command type by giving certain commands 
higher scheduling priority, the probabilities for the occurr- 
ence of interactions associated with "out-of-favor" commands 
will decrease as users abandon their use as being too time 
consuming. The P, can be changed by shifting "capacity" 
around the system; that is, by manipulating processor speeds. 
Comparisons between two systems without involving economic 
issues makes sense only if both have the same overall capa- 
city to execute instructions or to process interactions. 

If capacity is defined in terms of instructions per second 
or interactions per second, then manipulation of the Py 
which leaves the total capacity unchanged is subject to 

the following constraint: 
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Here C is the capacity of the entire system in inter- 
actions per second, and m is the total number of process- 
ors. A solution to the problem of minimizing W asa 


function of the a and Py is possible, but is best 


i 
taken up after a consideration of the two-processor, two- 
queue system in an unbalanced mode of operation. If the 
processors are unbalanced, the operation of the total sys- 
tem exhibits an interesting phenomenon as one of the pro- 
cessors saturates before the other. 

The following describes a specific example of a two- 
processor, two-queue system drawn from a real world situa- 
tion. Nature being what it is, this system is unbalanced. 
The effects of imbalance, possibly remedies for it, and 
differences in performance are all discussed. The example 
described has another merit in that an interesting actual 
situtaion is analyzed. 

Using the data concerning the mix of task types for 
the CTSS user (Section II), some predictions will be made 
on the cost and performance of a CTISS system augmented by 
an auxiliary special-purpose processor. Of the five types 
of tasks that CTSS performs, two of these can clearly be 
accomplished by a processor which is simpler than that of 
the IBM 7094 with little increase in the mean processor 
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times per interaction for these tasks. Specifically, the 
Program Input and Editing commands involve very little 

data processing. A simple character-oriented processor 
could probably do the same manipulations as are required 

of the 7094 processor in much the same time. Fewer instruc- 
tions would have to be executed since no unpacking and re- 
packing of characters is necessary in the character-oriented 
processor. Furthermore, such a processor would be con- 
siderably cheaper than an equivalent speed (for Input and 
Editing), general-purpose, parallel arithmetic, floating- 
point processor. The other type of task which a very sim- 
ple processor could perform is that of File Manipulation. 
The operations involved are simply that of controlling a 
disk channel so as to copy, concatenate, split, merge, etc. 
disk files. If such a processor were added to the present 
configuration, it would relieve the load on the central 
processor of the 7094 to the extent of handling nearly half 
of all of the interacting users, nearly half of all the 
interactions, and approximately 35 per cent of all users! 
processing requirements. First, the performance improve- 
ment brought about by the addition of this auxiliary, special- 
purpose processor will be analyzed; then a few general 
statements about the additional cost of the system will be 
made. . 


Essentially, the auxiliary processor will transform 
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CTSS into a two-processor, two-queue system. For the sake 
of simplicity, the assumption will be made that the aux- 
iliary machine is able to process interactions of the File 
Manipulation and Program Input and Editing types at the 
same speed as the IBM 7094 processor. Furthermore, assume 
that the swapping overhead is the same as in the normal 
version of CTSS (.39 of the total processor time per 
interaction). These assumptions are reasonable since the 
auxiliary processor will probably be somewhat Slower than 
the IBM 7094, but its swapping overhead will be lower due 
to its smaller programs and the possibility of "read-only" 
routines for common functions which are not swapped. Using 
the data of Section II and the definitions of the previous 


pages (processor number 1 will be the auxiliary): 


a, = 48 

a. = 052 

a a8 = 1.03 seconds . 
Po = ide = 1.82 seconds . 
qT, = 39.3 seconds . 

Ts = 31.3 seconds . 


W is found as described before and is plotted in 
Figure 16 along with the values for normal CTSS as a func- 


tion of the total number of interacting users. In both 
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Figure 16 : MEAN RESPONSE TIME VS. NO. OF INTERACTING USERS FOR CTSS AND “AUGMENTED" CTSS. 
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cases, the Markov model was used to obtain the Wy ° 

It is interesting to note, for example, that the "augmented" 
version of CTSS yields the same mean overall response time 
at 45 users as the normal CTSS does at 30. The 
distribution of overall response time for each system will, 
in general, have different shapes. The normal CTSS overall 
mean response time should have a smaller variance than that 
for the augmented system. Figure 17 shows a plot of the 
mean number of users interacting with each portion of the 
system as a function of the total number of users. Since 
the capacities of the two systems and the user preferences 
between them (the Os ) are nearly equal, the n,; are 
nearly equal until the total number of users in the system 
reaches approximately 40. At this point the values of 


the n diverge) The mean number of users interacting 


i 
with the less heavily loaded auxiliary processor remains 
constant at 21, and any additional users added to the 
entire system show up in the mean number of users interact- 
ing with the 7094 central processor. The reasoning which 
explains this phenomenon is that because the 7094 processor 
is more heavily loaded than the auxiliary one, the mean 
response time for the 7094 processor increases more per 
user added to the system than that of the auxiliary. As 


a response time increases, more users are held waiting for 


the corresponding processor on the average, and the response 
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Figure 17 : MEAN NUMBER OF USERS INTERACTING WITH EACH PROCESSOR OF AUGMENTED CTSS VS. TOTAL USERS. 
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time increases still more. This effect is analogous to 
a positive feedback situation in an amplifier-- saturation 
occurs. As the total number of users increases, the 7094 
processor is forced into saturation and holds more and more 
of the total number of interacting users, leaving the 
auxiliary processor with a steadily decreasing proportion 
of the user population. 

By manipulating either the Py or the &, » or 
both, both processors can be kept out of saturation or 
at least equally saturated. Taking the expression for 
ny presented in the previous discussion substituting for 


Wy + T, the value i yields an equation in terms 


of the Py ’ Leary » and as which must be satisfied in the 
steady-state: 

@5P5 _ OP 

(I- 02) 7 (I=) : 
Both processors can be kept equally saturated if the T's 
are set equal. This will insure that neither processor 
saturates leaving the other unsaturated (i.e., 7 _ = oO, 


re) 
and 4 # O ). Doing this yields the balance condition: 


Looking at the example under consideration and keep- 


ing the constant capacity restriction in mind, the only 
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way to achieve balance would be either to encourage 
users to shift their interaction mixes toward the File 
Manipulation and Program Input and Editing, or to speed 
up the 7094 processor (perhaps by installing a Model II 
7094) and allow a slight decrease in the performance of 
the auxiliary processor. 

Returning to the example, the effects of adding the 
auxiliary processor is to increase the number of users 
that can be effectively served by 50 per cent. The addi- 
tional cost of the system is just that of the auxiliary 
processor and the hardware necessary to simultaneously 
access a disk file from two different processors. Certain- 
ly, this additional cost will be well under 50 per cent 
of the cost of the IBM 7094 CTSS configuration. Any fur- 
ther discussion of costs at this point would involve going 


beyond the purposes of this example. 


3. Serial Multiple Systems 


A serial multiple system is one in which users! 
interactions are processed by two or more processors 
in sequence. That is, after a user completes the "think" 
time, his job requires Py seconds of processor time on 
the first time-shared processor, P, seconds on the second 
time-shared processor, etc. For two processors, the 
think time T and the response time of the first processor 
Wy) appear to the second Nesceseen as the actual think 


time. Therefore, using the results from the single-process- 


or Markov model: 


Similarly, for the first processor: 


1 
W = ~ W, od T e 
1 1-o1 2 


The solution to these two equations is simply obtained 
by adding them and solving for the net response time, 


W, + Wo: 
P P 
7 = 2 1 2 
Pe et. era a 


A serial system such as this one would be a good 
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model for a real system in all of the jobs processed 

by the main computer (processor 1) are then sent to an 
output computer for post-processing. For non-saturation 
operation, a relaxation technique such as described pre- 
viously must be used to find the steady-state values for 


W and W, 


1 » Separately. 
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V. CONCLUSIONS 


The purpose of this section is to analyze the gen-~- 
erality of the techniques and models presented as well 
as to summarize and discuss the specific results obtained. 
The use of mean response time as a performance metric is 
discussed and the generality of the techniques and models 
for predicting the performance of interactive time-shared 
systems is evaluated. Furthermore, results concerning 
the specific systems studied are outlined and analyzed. 

The most important performance aspect of any man- 
machine system is the quantity of results obtained (in 
terms of "significant" problems solved) per unit time. 

At this time, such a quantity is unmeasurable. The pro- 
ductivity of a machine user might be represented in simpler, 
more tractable terms. By excluding an evaluation of the 
relative merits of the problems solved, productivity can 

be measured in terms of sub-solutions (or "micro-solutions" 
obtained per unit of time. In this way the use of time 

rate of interaction can be defended as being a well-defined, 
measurable quantity which approximates (however roughly) 

the ultimate performance metric. Since the number of inter- 
actions per unit time can be derived in terms of the response 
time and the user think time distributions and because the 


use of the response time allows the machine performance to 
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be separated from users' performance, the distribution of 
response times was chosen to be the primary system perfor- 
mance measure. Other parameters of interest, such as 

the mean number of users queued at a particular processor, 
can be derived from mean response time. 

The problem can also be viewed from the hardware 
aspect. A system which performs a useful processing func- 
tion at a certain performance level and cost (measured 
both in hardware and user time) is clearly "better" than 
a functionally equivalent one with the same performance 
level but a higher cost. In a sense, a measure of cost 
is the complexity and duty factor (percentage of use) of 
the hardware portion of the system. Moreover, there is an 
infinite variety of possible information processing ser- 
vices that can be utilized by a user, and an infinite nun- 
ber of possible system organizations to provide him these 
services. The tasks a system performs, as well as the 
level of acceptable performance and hardware complexity, 
are obviously important issues. However, primary attention 
is paid to system performance as characterized by the dis- 
tribution of response times which are, in turn, derivable 
from the characterizations of both the user and the inter- 
active system. 

There are many metrics which can be used to describe 


a distribution of response times. For some purposes the 
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maximum might be equated with the "worst-case"; the minimum, 
with the best achievable service. The mode of the distri- 
bution indicates the most probable level of service. A 
simple metric such as the mean (with or without a measure 

of expected deviation) characterizes most of these aspects, 
is computed readily, and is extremely useful in modeling. 
For this reason, it will be used as the principle character- 
izing feature of interactive performance. 

A fairly simple model for a generalized interactive 
system can be developed in terms of the mean response times. 
This model can be viewed as an arbitrary network of unilateral 
delays through which the processes necessitated by user 
interaction pass. The delays are of two types: those due 
to the user, and those due to the hardware system. User 
causes delays represent the time it takes for users to ob- 
serve console output from previous interactions, to think 
over their next moves, and finally to produce console input 
which will request further services from the hardware system. 
All of these activities are lumped under the single term 
"thinking", The system induced delays represent the response 
times of the various sub-systems which comprise the hard- 
ware portion of the entire interactive system. Each node 
in the network may have any number of branches entering or 
leaving it as long as there is at least one in each direction. 


Each branch leaving a node has a probability of its being 
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selected by a user in preference to the others. This 
probability is a function of the specific service or type 
of interaction selected by the user. The allocation of 
hardware resources to various jobs by the system will be 
taken into account in the processing delays. In general, 
the delays and probabilities may be any arbitrary function 
of the state of the entire system or its past history. 

The user induced delays represent the think times for various 
types of interactions. The processing delays take into 
account the capacity of the processors, the distribution 
of processor time, etc. for the particular type of inter- 
actions being delayed. 

There may be portions of the system which are inaccess- 
ible to a number of its users. After assuming that certain 
numbers of users are interacting with each portion, the 
object is to determine the steady-state values of every 
delay in the network. In general, there may not be a 
steady-state solution if arbitrary delay functions are 
allowed. However, if all delays are positive and do not 
decrease with the addition of users to the corresponding 
branch, an analogy can be made to passive electrical circuits; 
and the existence of a steady-state solution can be shown 
to always exist. 

A sub-class of this generalized interactive system 


model has been analyzed. This sub-class differs from the 
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general model because of two simplifying constraints. 
First, the probabilities for choosing an exit branch from 
a@ node are assumed to be constants. These probabilities 
represent the users! choice of interaction types. Since 
the CTSS data showed that the mix of the five interaction 
types remained nearly constant from day-to-day over a period 
of more than two months (see Section II, Part C), this 
simplication is justifiable. Secondly, there are restric- 
tions on the functional dependence of the delays. In all 
of the systems discussed, the think times were constants. 
This was done on the basis of the CTSS data, as was dis- 
cussed in Section II, Part C. The only restriction on 

the delays is that they be some known function of the flow 
of users' interactions through the network. 

The processing delays were determined with the use of 
the single and multiple-processor Markov models, but they 
may be determined by simulation of the individual sub-systems 
themselves. Note that it should not be necessary to simu- 
late the entire interactive system-- simulation is necessary 
only for those portions of the system which are not mathe- 
matically analyzable. In some cases, it may be necessary 
to do a few simulations of a sub-system in order to determine 
the net processor time per interaction. That is, the pro- 
cessor time per interaction required by the user is known, 


but the effective expansion of this processor time due to 
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overhead factors such as non-overlapped swapping, etc., 

may have to be determined by simulation. The Markov 

models are useful if: (1) the sub-system is time-shared; 
and (2) the net processor time per interaction is a simple 
function of the processor time the user originally requires. 
This second condition can be amplified by the observation 
that the terms ) and (d) in the original rate matrices 
for the Markov models (see Section III, Parts D and E) can 
easily be made into more complicated functions and still 
be soluble for the steady-state occupancy probabilities. 

If the system is not time-shared (in the sense used in 

this report ) or the accuracy of the Markov models is not 
sufficient, some other Markov process or method of. analysis 
can be employed. The delay networks for a few specific 
examples of interactive systems are shown in Figure 18. 

It may be the case that processor time per interaction 
is not the appropriate parameter because the processor is 
not the rate-determining factor in a sub-system. In all 
of the examples studied, the processor speed determined the 
basic rate of operation. It may well be that there exist, 
or will someday exist, systems whose rate-determining ele- 
ment is, for example, the bulk storage device. For such 
a case, it might make more sense to use the term "bulk 
storage use per interaction" rather than "processor time 


per interaction". Thus, in all of the discussions of pro- 
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Figure 18 : Delay Networks for Some Interactive Systems. 
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cessor time, the possibility of substituting the time 
required for some other device should be kept in mind. 

At this point, some observations will be made about 
the specific systems studied. First, some general remarks 
concerning the operation of CTSS-like systems will be 
presented and then some of the implications of the specific 
results obtained will be analyzed. 

Perhaps the most important result of the research 
in this report is that time-shared systems and their users 
can be successfully modeled. The consistent, predictable 
behavior of users interacting with time-shared systems 
was not a foregone conclusion at the onset of the research-- 
it had to be established. That a simple model is sufficient 
to represent a time-shared system user did not come as a 
complete surprise, but neither was it obvious from consid- 
@wing the situation a priori. The same statement can be 
made of the modeling of CTSS. The accuracy of the single- 
processor Markov model in predicting the CTSS mean re- 
sponse time function was somewhat more surprising. The 
implications of this accuracy will be discussed later in 
this section. 

As was seen during the discussion of mean response 
time as a function of the number of interacting users, 
(Section IV, Part A), the operation of CTSS can be split 


into two segments-- saturated and unsaturated. The exact 
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point of crossover between these two regimes of operation 

is somewhat hazy since saturation can only be defined with 
reference to a probability. That is, a time-shared system 
enters saturation when the probability of zero users waiting 
for service becomes less than some small number. Theoret- 
ically, the point where there is zero probability of an 
empty queue does not exist except for an infinite load on 
the system. The most important factor in determining when 

a system enters saturation is the mean net processor time 
per interaction. In non-saturated operation, the addition 
of another interacting user has little effect on the mean 
response time of the system; whereas for saturated operation, 
an additional user makes a noticeable difference. There 

is a distinct difference in the way a CTSS-like system re- 
sponds on the two sides of the saturation point. The diff- 
erence in mean response time for loads of twenty and thirty 
users is much more noticeable (to the CTSS user) than the 
difference between loads of ten and twenty users. 

Another interesting phenomenon is the effect that 
changes in the performance of a time-shared system have on 
the behavior of the users. All of the data and results 
presented so far in this report were taken during a period 
wnen the operating characteristics of CTSS were stable. 
However, if a heavily used command is changed so that its 


average processor time is increased (thus increasing the 
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mean response time), users are likely to decrease their 
usage of this command. If a new command is added which 
accomplishes the same function as an established command 
in a faster or more elegant manner, changes in the distri- 
butions of think time and processor time per interaction 
should be expected. 

There are other factors which can affect user char- 
acteristics. If the scheduling procedure gives low priority 
to a user's program because of one of its characteristics 
(e.g-5 program size), users seem to try to eliminate these 
"objectionable" features from their programs and interaction 
usage (e.g., attempt to write and use smaller programs). 
Thus, it seems that scheduling, if properly executed, could 
be used to "mold" the users to some extent by assigning 
priority on the basis of job type, program size, program 
running time, user think time, etc., etc. Then the user, 
in trying to "beat the system", will tend to conform to 
the image of what the writers of the scheduling program 
considered to be the ideal user. Fortunately (or unfortun- 
ately) users are generally not so flexible that they can 
all arrange their usage so as to always be in the highest 
priority group. If users were this flexible, all would 
have the same priority; and any scheduling procedure, no 
matter how complex at the onset of its use, would result 


with simple round-robin behavior. 
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The fact that the single-processor Markov model 
produces accurate predictions of the mean response time 
as a function of the number of users interacting with the 
system has several interesting implications. The model 
(see Section III, Part D) is a highly simplified version 
of the processes occurring in a highly complex hardware- 
software system. Many features which would seem essential 
to the operation of actual time-shared systems are not 
present in the Markov model: swapping (except as a constant 
overhead factor), quantum time, priority scheduling, etc. 
Moreover, the distributions of think time and processor 
time per interaction are fit in the model by exponentials 
with the proper means. The fact that all of this detail 
may be omitted and still leave a model which accurately 
predicts mean response time is startling. The implication 
is that only mean think time, mean processor time (including 
swapping), and the number of users interacting with the 
system are of first order effect, and that the rest of the 
details have second or third order effect. 

It might be possible to obtain better mean response 
times than those predicted by the Markov model by the use 
of a "shortest job first" procedure. The ability to predict 
accurately the length of a job is essential to such a sched- 
uler. As the accuracy of its prediction mechanism is re- 


duced, performance rapidly approaches the level of a first-~- 
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come, first-served or random scheduler. 

The chief effect of the quantum size (except in pre- 
dicting schedulers) is to change the swapping overhead 
and thereby affect the mean response time. In a system 
where the quantum time has no effect on the swapping over- 
head (such as in a system with complete swapping overlap), 
the quantum size has no effect on the mean response time. 
The quantum size, however, always has an effect on the 
shape of the distribution of response times. 

There is no reason to believe that the Markov model 
for a multiple-processor system serving a single-queue of 
users is not just as accurate as the single-processor model. 
The results it predicts are completely reasonable: that 
for equal capacity systems, the performance of the single- 
processor system will be better than that of the two-processor 
system. Furthermore, given equal capacity systems with 
the same number of processors, the system with the fewest 
number of queues will yield the best performance. Extra- 
polating these results, the conclusion can be made that 
for equal capacity systems, the fewer the number of processors 
and queues, the better the mean response time. The obser- 
vation should be made that at saturation, all equal capacity 
systems have the same performance, and a system with fewer 
processors should require no less main storage or swapping 


activity than a system with more processors. However, if 
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traditional computer economics hold, the fastest possible 
processor will provide the best processing capacity per 
dollar. 

Polymorphic systems, appearing to yield the worst 
performance from the equal capacity comparison, begin to 
be very attractive with the introduction of economic 
considerations. In the example discussed (see Section IV, 
Part D-2), the performance of CTSS could have been improved 
to the point of allowing approximately 45 users to be 
served with the same mean response time as 30 with the 
addition of hardware representing less than ten per cent 
of the monthly rental of CTSS (an IBM l#-- and an additional 
channel and file control for the 1302 disk). 

What constitutes acceptable response time is a ques- 
tion that is completely open to discussion. However, there 
is certainly no relationship between the point at which 
@ system saturates and whether or not the response times 
at that point are acceptable. Thus, the question of whether 
or not it is desirable to operate a system in saturation 
must be settled by other considerations. Given a maximum 
acceptable mean response time, the maximum number of users 
to be served, and a specification of user characteristics, 
the most desirable system meeting these requirements will 
be the cheapest. The cheapest system is very likely to 


be the one with the lowest processing capacity consistent 
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with meeting the specifications. This system will be run 
in saturation. 

So far in this discussion, most of the results cited 
were derivable from considerations of the CTSS data and 
the Markov models. There are, of course, many factors 
which the Markov model cannot be made to predict, and a 
more detailed model must be used. As was seen, the simula- 
tion models were able to predict the distribution of re- 
sponse times, hardware usage, response time as a function 
of processor time required, etc. Most of these parameters 
were discussed sufficiently when they were presented. 
Perhaps the most interesting result of the simulations is 
the fact that good accuracy can be obtained from a fairly 
simple model (when compared to the actual system). The 
biggest problem in simulation modeling, as in all model 
building, is to retain all "essential" detail and remove 
the non-essential features. It is felt that the efforts 
in this direction in the case of the simulation models 
was successful. 

Summarizing the overall accomplishments of this re- 
search, the proof that time-shared systems and users can 
be accurately modeled is of first importance. Secondly, 
if mean response time is of primary interest, simple mathe- 
matical models can be constructed having good generality 


and yielding accurate results. Excellent predictions of 
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parameters other than mean response time can be obtained 
from more detailed, but still highly simplified simula- 


tion models. 


pil 
APPENDIX A - DESCRIPTION OF CTSS 


1. The CTSS Hardware 


Simply stated, the CTSS configuration is an IBM 7094 
(Model I) computer, augmented by disk and drum storage, 
connected through an IBM 7750 transmission controller to 
users! remote consoles, each consisting of a keyboard 
and printer. By typing at the console, a user may commun- 
icate with either the CTSS Supervisory Program or a pro- 
gram activated by this Supervisor. A line of input inter- 
preted by the Supervisor is called a "command". Commands 
cause programs to be loaded from disk storage. These 
programs are queued, and each is executed for a short 
period of time, not necessarily to completion. The se- 
quence of programs to be run and the duration of each 
"purst" of processor time is determined by a sub-routine 
in the Supervisor called the "Scheduling Algorithm". The 
following is a list of the hardware elements in the sys- 
tem and a brief description of the function of each. 

1. Central Processing Unit (CPU) - normal 7094 with 
the addition of automatic relocation and memory 
protection. Automatic relocation is not used on 
the present system as all programs are loaded be- 
ginning with location zero. In the protection 


mode, all memory references are checked against 
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pre-set "memory bounds"; and if an out-of-bounds 
reference occurs, the CPU is trapped. Programs 
are given only enough space as is required. The 
limits on this space are location zero and the 
memory bound. In addition, the execution of any 
channel operating or tape handling instructions 
causes a protection mode violation and a trap to 
the Supervisor. In addition, an Interval Timer 
is also attached. This device can cuase a trap 
after a program-specified time interval. The 
time unit is 1/60-th of a second. 
Core Memory - 2 modules of 32,768 36 bit words. 
The two units are designated "Core A" and "Core B". 
These units do not operate independently, and 
only one of them can operate during a given cycle. 
The access time is 2 microseconds. Core A holds 
only the CTSS Supervisory Program and Core B is 
used to hold users' programs as they are being 
executed. 
The system configuration during the time the data 
was taken consisted of up to seven I/O channels: 
a. Conventional tape channel with six tapes, 
printer, punch, and card reader. Used for 
batch-processed programs only. 


b. Conventional tape channel with six tapes. 
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Used for batch-processed programs only. 
Direct Data Channel ~ used to connect non- 
standard I/O devices to system. At present, 
only the Electronic System Laboratory's 
Display Console is connected. This unit 
consists of a CRT, light pen, buttons, etc. 
Displays are originated and maintained by 
the 7094, but light pen tracking and coor- 
dinate rotation, translation, and expansion 
are done by local circuitry. 

Disk and Drum Channel and File Control - 

A 1301 Model 2 disk file and a 7320 drum 
were connected. The 1301-2 contains 20,000 
tracks of 466 words each. Access time con- 
sists of arm positioning, 16 ms. average, 
and rotational delay, 19 ms. Words are 
transmitted at a rate of 66.6 microseconds/ 
word. This disk was replaced by a 1302 
Model 2 disk on January 12, 1965, but be- 
cause of the way it was used its character- 
istics remained practically the same as the 
1301-2 for the period of the monitoring. 

The 1302-2 has a capacity of 40,000 tracks. 
A 466 word track size was used (half capa- 


city) to maintain system continuity while 
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new system programs were developed. The 
drum has a capacity of 186,400 words (400 
tracks). Reading heads are switched elec- 
tronically so that the average access time 
is just the average rotational delay, 8.6 ms. 
The transmission rate is approximately 30 
microseconds /word. 

IBM 7750 Transmission Control - a stored 
program computer used to coordinate input- 
output through a telephone switchboard to 
user's consoles, IBM 1050's and Teletype 
Model 35's. Both of these units type out- 
put at approximately 10 characters per sec- 
ond, including the timing for carriage 
returns. 

Disk and Drum Channel and File Control - 
Same as Channel D. 

High Speed Drum Channel and File Control - 
A model 7320A drum is used with a capacity 
of 208,608 words, access time of 8.6 ms. 
average, and transmission rate of approxi- 
mately 9 microseconds/word. On the install- 
ation of this channel (September 14, 1964), 
Channel F was removed and its disk and drum 


files were placed on Channel D. The 1302 
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Model 2 replaced both 1301-2 disks on 


January 12, 1965. 


The almost 20 million words (40,000 tracks) of disk 
file storage are primarily for the use of the approximate- 
ly 300 CTSS users at Project MAC. Each user is allotted 
between 50 and about 1000 tracks of space for his own use. 
Typically, a user's tracks will contain files of source 
decks of programs in MAD, FAP, FORTRAN, etc., binary decks 
ready for the conventional BSS loader, data files, core- 
images, etc. A core-image is an exact copy of the contents 
of the core memory after a program has been loaded, linked, 
and possibly run, along with the status of the CPU. The 
core-image is only as long as it has to be; unused cells 
are not saved. The CTSS Supervisory Program has an area 
on the disk which is used to hold the core-images of nearly 
80 command programs, a library for the BSS loader, etc. 

Drum storage is used to hold core-images of user pro- 
grams queued for execution. When a user's program is select- 
ed for running, it is transfered from the drum to Core B. 
The core-image previously in Core B is dumped to the drun. 
However, only the CPU status and enough of the old core- 
image to make room for the new one is placed on the drum. 
All core-images are always loaded into Core B starting 
at the first location, thus there will never be more than 


one complete core-image in Core B at a time. Other core- 
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images, aS many as four, may be split between Core B and 
drum storage. This process of dumping and loading user's 


programs is called "swapping". 
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2. The CTSS Software 


Users are assigned one of six internal states: 


c¢) 


Dead. User has no core-image on the drum and 

is not waiting for service. 

Dormant. User has a core-image on the drum, but 
is not waiting for service. 

Working. User has a core-image and is being serv- 
ed. That is, his program is either being run by 
the CPU or it is in the queues waiting for service. 
Waiting Command. User has no core-image and is 
waiting to be given service for the first time. 

A core-image will be obtained from the disk and 
when loaded, the user's status will be changed 

to "Working". 

Input Wait. The user's program required console 
input. The core-image is on the drum, and the 
user is no longer in the queves. Upon completion 
of a line of input, the user is placed back into 
the Working state. 

Output Wait. The user's program has filled its 
console output buffers and attempted to add more. 
After the buffer empties to a certain point, the 
user is returned to the Working status and further 


output can occur. While a user's program is in 
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Output Wait, the core-image is on the drum, and 


the user is no longer in the queues. 


The difference between the Dead and Dormant states 
is simply whether or not a user is left with a core-image 
after a command program finishes. Most commands finish 
in the Dead status. However, commands for the loading, 
linking, and running of BSS files leave a core-image. 
This is done so that post-mortems, traces, etc. may be 
initiated. In addition, any program can be stopped by 
the user from his console by typing a special character 
sequence. This action, called a "quit", puts the program 
into Dormant. It may be restarted at any time by the 
appropriate command. A core-image may be saved on the 
disk in a permanent file and then restored at a later time 
by the appropriate sequence of commands. 

Swapping and the use of the CPU are non-overlapped 
in the version of CTSS studied. During either of these 
activities, control is returned to the Supervisor via 
traps for various reasons. Every time a character is re- 
ceived at the 7750 from a console, the 7750 channel traps 
the 7094 CPU. The input character along with a source 
identification is immediately transmitted to Core A, with 
no processing being done. Every 200 milliseconds a clock 


trap occurs. At this time all input characters received 
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since the previous clock trap are sorted by user and 
appended to the corresponding input line. Any user sta- 
tus changes brought about by the completion of an input 
line are communicated to the Scheduling Algorithm. Out- 
put from programs is handled in much the same way except 
that the buffering is in the 7750. 

Whenever the Scheduling Algorithm determines that a 
user's program is to be stopped or pre-empted, the swapp- 
ing procedure is started. Priorities are assigned user's 
programs on the basis of length and previous running time. 
In order to keep efficiency up, longer programs are given 
slightly less priority because. they require longer swapp- 
ing time. Longer programs, when they finally are to rum, 
are usually allowed a longer period of CPU time. In more 
detail, the Scheduling Algorithm has nine queves in which 
users wait. These queves are ordered; the zeroth queve 
has the highest priority, the eighth, the lowest. When 
users enter the Command Wait status from Dormant via a 
command, a queue assignment is made based: on the size of 
the command core-image. If the memory bound is greater 
than 4096, queue number three is assigned, otherwise queue 
number two. The next user to run is always selected from 
the highest priority, non-empty queue. If a user remains 
in the same queve for more than 60 seconds without being 
run, he is moved to the end of the next higher priority 
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queue. 

A user is normally allowed a burst of CPU time equal 
to .5 seconds multiplied by 2 to the power of the user's 
queue number. Thus, a user of level 3 would normally run 
for (.5)(2)(2)(2) = 4 seconds. If a user exceeds this 
time while running, he is removed from his present queue 
and placed at the end of the next lower priority one. A 
user is pre-empted, that is, another user will be swapped 
in, if the current user is no longer the first user in 
the queues, and he has run as long as the new first user 
will run, computing the burst as above. When a user re- 
turns to the Working status from Input or Output Wait, his 
queue number is re-computed by size as above, but it re- 
mains the same if it is already as good as or better than 
queue 2. If a user goes from Dormant to Working vis a 
program generated "sleeping period", the old priority level 
is used. If a program generated command is encountered, 
the new queve is either the old one or is computed by size, 
whichever yields the lower priority. A listing of the 


Scheduling Algorithm appears below. 
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Reeeaereaecee TIME SHARING SCHEDULING ALGORITHM *#*annawnnananne 
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T. HASTINGS AND R. DALEY 
THE SCHEDULING ALGORITHM PERFORMS THE FOLLOWING FUNCTIONS 


1. DETERMINES WHICH USER IS TO RUN NEXT 

2. DETERMINES WHEN NEXT USER IS TO RUN 

3. DETERMINES HOW LONG NEXT USER 1S TO RUN 

4, CHARGES USERS FOR SWAPPING AND RUNNING TIME 
5. KEEPS TRACK OF THE STATUS OF EACH USER 


THE SCHEDULING ALGORITHM IS CALLED FROM THE SUPERVISOR BY 
EXECUTE SCHED. (EVENT, USER, ARG) 
AFTER ALL TRAPS HAVE BEEN DISABLED 
‘USER' IS BETWEEN 0 AND THE MAX. NO. OF USERS, 'MXUSR 
THE SIGNIFICANCE OF 'USER' AND 'ARG' DEPEND ON ‘EVENTS 
OR ARE MEANINGLESS AS DESCRIBED BELOW 
"EVENT' DESCRIPTION 


0 INITIALIZATION OF SCHED, 

1 CLOCK INTERRUPT 

2 "USER' HAS CHANGED TO STATE ‘ARG’ 

3 BEGINNING OF SAVING "USER" CORE IMAGE 

4 BEGINNING OF RESTORING ‘USER’ CORE IMAGE 
5 'USER' BEGINS RUNNING, AFTER SWAP 

6 ‘USER’ CORE IMAGE NOW HAS LENGTH ‘ARG' 

7 OPERATOR SET BACKGROUND KEYS TO ‘ARG' 

8 "USER' LOGGED IN, 'ARG' IS LINE MULTIPLIER 
9 "USER' LOGGED OUT 

10 IS 'NEWUSR' STILL RUNABLE 

11 ‘USER' DIALED UP COMPUTER 


TO CLARIFY THE ORDER IN WHICH EVENTS HAPPEN, BLOCKS 
OF CODING BRACKETED BY COMMENTS HAVE BEEN PLACED IN 
TYPICAL ORDER OF EXECUTION FOR A COMMAND 

ALL TIME IS KEPT IN SIXTIETHS OF A SECOND AND VARIABLES 
ENDING WITH 'TIM' ARE TIMES SINCE SYSTEM WAS 

_ LOADED WITH THE EXCEPTION OF ‘SYSTIM' 

SCHED. HAS SOLE RESPONSIBILITY GOR SETTING AND CHANGING 

THE FOLLOWING COMMON ARRAYS AND VARIALBES 


THE FOLLOWING COMMON ARRAYS ARE USED 

"STATUS' - THE STATUS OF EACH USER 

WHERE STATUS(J) MAY BE 

DEAD - NOT WAITING TO RUN AND NO CORE IMAGE 
DORMNT - NOT WAITING TO RUN 
WORKING - WAITING IN QUEUES OR RUNNING 
WAITING COMMAND - WAITING IN QUEUES FOR COM, 
INPUT WAIT - PROGRAM WAITING FOR INPUT 
OUTPUT WAIT - OUTPUT BUFFERS FILLED 
‘LENGTH! - LENGTH OF USER CORE IMAGE IN WORDS 
"LEVEL" - USER'S PRIORITY LEVEL(O, ... , ‘MAXLVL") 
‘TIMLEV' - ELAPSED TIME RUN AT CURRENT LEVEL 
‘WATTIM' = THE LAST TIME THAT A USER BEGAN TO WAIT 
"LINMUL' - USER LINE MULTIPLIER 
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"PLIST' - THE POSITION LIST SPECIFIES THE POSITIONS 
OF THE USERS WHICH ARE IN THE WORKING QUEUE 
‘ULIST' - THE USER LIST INDICATES THE USER NUMBERS 
WHICH CORRESPOND TO THESE QUEUE POSITIONS 
"ENDPTR' - ENDPTR(J) |S END OF QUEUE J IN PLIST 
"NOTIME' - NOTIME(J) IS SET TO 2 IF USER INACTIVE 
AND USER J WILL SUBSEQUENTLY 8E LOGGED OUT 


THE FOLLOWING COMMON VARIABLES ARE USED 
"MXUSRS' - MAX. NO. OF FOREGROUND USERS 
"CURUSR* - CURRENT USER, RUNNING OR SWAPPING 
‘OLDUSR' - LAST USER TO BE RUN, WHEN 'SWAP' ,NE. 0 
"NEWUSR* - NEXT USER TO BE RUN, WHEN ‘SWAP' .NE. 0 
*PAYUSR' ~ THE USER CURRENTLY PAYING FOR TIME 
"SYSTIM' - TIME SYSTEM WAS INITIALIZED 
*BEGTIM' - THE LAST TIME 'CURUSR' BEGAN TO RUN 
"QUANTM' - MAXIMUM RUNNING TIME AT LEVEL 0 
"MAXTIM' = USER RUNS AT SAME LEVEL UNTIL ‘MAXTIM! 
'TBASE' - BASE TIME FOR COMPUTING 'MAXTIM' 
"PAYTIM' =~ LAST TIME A USER WAS CHARGED FOR TIME 
"LEVTIM' - LAST TIME 'CURUSR’ WAS RUNNING AT CURRENT LEVEL 
"SWAP' ~ NON-ZERO REQUESTS SUPERVISOR TO RUN 

"NEWUSR' AS SOON AS IT CAN 
"MAXLVL' = THE MAXIMUM PRIORITY LEVEL(O ... ‘MAXLVL') 
"'MINLVL' - THE MINIMUM PRIORITY LEVEL ALLOWED 
‘FULLVL' - INIT, LEVEL FOR ‘FULLEN' TO FULL CORE USER 
"EMPLVL' - INITIAL LEVEL FOR EMPTY CORE USER 
"FULLEN' = LENGTH FOR ENTRY AT LEVEL ‘FULLVL' 
"PB! - GUARANTEED PERCENTAGE FOR BACKGROUND 
‘QNTWAT' - QUANTM WAITING TIME BEFORE LEVEL CHANGE 
TO NEXT HIGHEST PRIORITY LEVEL 

"LEVINC’ - AMOUNT PRIORITY LEVEL IS INCREASED WHEN 

USER RETURNS TO WORKING FROM INPUT OR OUTPUT WAIT 
"ENACTV' - MAX, TIME INACTIVE BEFORE LOGOUT 
"HANGUP" - MAX. TIME BEFORE INACTIVE LINE 1S HUNGUP 


COMMON VARIABLES REFERRED TO BY SCHED. 8UT 
NOT SET OR CHANGED BY SCHED. 
"BKGTIM' - TOTAL TIME BACKGROUND HAS RUN 
"SWPSW' - NON-ZERO WHEN SUPERVISOR 1S SWAPPING AND 
COMMAND LOADING 
"PROBN(J)' ~ NON-ZERO WHEN USER J IS LOGGED IN 
‘ADOPT(J)' - PROBN(J) .AND. ADOPT(J) .E. 18, THEN 
USER J IS ADOPTED 


SCHED. CALLS THE FOLLOWING SUBROUTINES 
INITQ. - INITIALIZES QUEUES 
HEDUSR. - RETURNS THE HEAD OF QUEUE USER 

AT HIGHEST NON-EMPTY PRIORITY LEVEL OR 0 
DELQUE.(J) - DELETES USER J FROM QUEUES 
ENDQUE.(J) - PLACES USER J AT END OF QUEUE LEVEL(J) 
BEGQUE.(J) - PLACES USER J AT BEG OF QUEUE LEVEL(J) 
1LOG2.(N) + RETURNS INTEGER PART OF LOG TO BASE 2 N 
1.€J) = CONVERTS FORWARD INDEX ‘J' TO BACKWARD 
INDEX FOR REFERRING TO MAD ARRAYS 
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INITIM, - INITIALIZE TIME ACCOUNTING 
INTIM, - USER 'U' LOGGED IN 
OUTIM. ~ USER 'U' LOGGED OUT 
CHARGE.(U,T) - CHARGE USER ‘U' FOR TIME 'Tt 
GETOTL. + RETURNS THE TOTAL TIME SYSTEM HAS RUN 
DELTIM.(T) - RETURNS DELTA 'T' = THE DIFFERENCE 
BETWEEN 'GETOTL.()' AND TIME 'T' 

TIME 'T' 1S ALSO SET TO GETOTL.(0) 
CURTIM,(0) - RETURNS THE CURRENT TIME SINCE MIDNIGHT 

OF DAY SYSTEM WAS INITIALIZED 
MONSCL. (EVENT, USER, ARG) MONITORS SCHED, 
MONSC2, IS CALLED WHEN SCHED. CHANGES COMMON 
PLOT1.(EVENT, USER, ARG) PLOTS SYSTEM ON ESL SCOPE 
PLOT2. IS CALLED WHEN SCHED. CHANGED COMMON 
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EXTERNAL FUNCTION(CA, B, C) 

ENTRY TO SCHED. 

NORMAL MODE IS INTEGER 
R 
R.. SHORTEN LINKAGE, SETUP USER INDEX, CALL MONITORING SUB., 
Re. CALL PLOTTING ROUTINE 
Ree ASSUME COMMON WILL BE CHANGED, AND DISPATCH ON 'EVENT' 
R 

EVENT = A 

USR = B 

IUSER = 1.(USR) 

ARG = C 

EXECUTE MONSC1. (EVENT, USR, ARG) 

EXECUTE PLOTI1.(EVENT, USR, ARG) 

MONITR = CHANGE 

STATEMENT LABEL MONITR, RETURN, CHANGE 

TRANSFER TO EVNTCEVENT) 
R 
Ras ‘EVENT’ .E. 0, INITIALIZE SCHEDULING ALGORITHM FOR N USERS 
Ree INITIALIZE INDEPENDENT COMMON VARIABLES 


EVNT(0) MXUSRS = 31 
MAXLVL = 8 
MINLVL = 0 
FULLVL = 3 
EMPLVL = 2 
FULLEN = 4096 
PB = 0 
QNTWAT = 3600 
LEVINC = 0 
QUANTM = 30 
TBASE = 0 


INACTV = 216000 

HANGUP = 7200 
R 
Ree INITIALIZE QUEUES AND TIME ACCOUNTING 
EXECUTE INITQ. 

EXECUTE INITIM. 
R 
Ree INITEALIZE TABLES 

THROUGH JLOOP, FOR J = 0, 1, J .G. UMAX 
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JUSER = 1.(J) 
JLOOP LINMUL(JUSER) = 1 
R 
R.. SET BACKGROUND(USER 0) TO RUN 
Re. USER 0 1S ALWAYS IMPLICITLY AT END OF QUEUES 
SYSTIM = CURTIM.(0) 
STATUS(!.(0)) = 2 
SWAP = 1B 
FIRST3 = 1B 
BGMAX = 180 
TRANSFER TO CHANGE 
R 
R.. ‘EVENTS .E. 1, CLOCK INTERRUPT 
Ree ASSUME COMMON WILL NOT BE CHANGED 
EVNT(1) MONITR = RETURN 
ICUR = 1. (CURUSR) 
T = GETOTL.(0) 
R.. DO THE FOLLOWING CHECKING EVERY 10 SECONDS 
Ree CHARGE PAYING USER FOR TIME 
Ree MOVE LONG WAITING USERS UP IN PRIORITY 
R.. ALSO LOGOUT INACTIVE USERS 
Ree AND HANGUP INACTIVE LINES 
WHENEVER T .G. CHECKT 
CHECKT = T + 600 
EXECUTE CHARGE.CPAYUSR, DELTIM,.(PAYTIM) ) 
THROUGH KLOOP, FOR K = 1, 1, K .G. UMAX 
WHENEVER K .E. CURUSR, TRANSFER TO KLOOP 
KUSER = 1.(K) 
DELT = T ~- WATTIM(KUSER) 


WHENEVER STATUS(KUSER) .E£. 3 .OR,. STATUS(KUSER) .E. 
WHENEVER DELT .G. QNTWAT .AND, LEVELC(KUSER) .G. MINLVL 


MONITR = CHANGE 
EXECUTE DELQUE.(K) 
LEVEL(KUSER) = LEVEL(KUSER) - 1 
EXECUTE ENDQUE.(K) 
WATTIMCKUSER) = T 
TIMLEV(KUSER) = 0 
END OF CONDITIONAL 
OR WHENEVER PROBN(KUSER) .NE. 0 
WHENEVER DELT .G. INACTV .AND. LINENO(KUSER) .E. 
MONITR = CHANGE 
NOTIMECKUSER) = 2 
WATTIMCKUSER) = T 
END OF CONDITIONAL 
OTHERWISE 
WHENEVER DELT .G. HANGUP .AND. ADOPT(KUSER) .E. 
MONITR = CHANGE 
NOTIME(KUSER) = 4& 
WATTIMC(KUSER) = T 
END OF CONDITIONAL 
END OF CONDITIONAL 
KLOOP CONTINUE 
END OF CONDITIONAL 
R 


R.. MOVE LONG RUNNING 'CURUSR' DOWN IN PRIORITY 


EVNT(6) 


EVNT(2) 
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WHENEVER CURUSR .NE. 0 .AND. T .G. MAXTIM 
1 «AND. «NOT. SWAP 

MONITR = CHANGE 

EXECUTE DELQUE.(CURUSR) 

WHENEVER LEVELCICUR) .L. MAXLVL, 


1 LEVELCICUR) = LEVELCICUR) + 1 
EXECUTE ENDQUE.(CURUSR) 
LEVTIM = T 


TIMLEVCICUR) = 0 
MAXTIM = T + TRUN.(CURUSR, LEVELCICUR)) 
END OF CONDITIONAL 
TRANSFER TO DECIDE 
R 
R.. 'EVENT' .E. 6, 'USR'C'IUSER') CORE IS OF LENGTH 'ARG' 
Ree JUST BEFORE ENTERING WAITING COMMAND 
R.. OR LENGTH CHANGED WHILE RUNNING 
LENGTHCIUSER) = ARG 
WHENEVER USR .E. CURUSR 
LEV = LEVELF.(LENGTHCIUSER) ) 
WHENEVER LEV .G. LEVEL(IUSER), 
1 MAXTIM = BEGTIM + TRUN.(CURUSR, LEV) - TIMLEV(IUSER) 
END OF CONDITIONAL 
TRANSFER TO CHANGE 
R 
R.. 'EVENT' .E, 2, 'USR'('TUSER') CHANGED STATE 
Ra. DISPATCH ON NEW STATE, IGNORE REDUNDANT TRANSITIONS 
WHENEVER USR .NE. 0, TRANSFER TO STATCARG) 
TRANSFER TO RETURN 
R 
R.. "USR'('IUSER’) BEGAN WAITING FOR A COMMAND 


STAT(3) LEV = LEVELF.CLENGTHC(IUSER) ) 


COMAND 


EVNT(10) 


WHENEVER STATUSCIUSER) .£. 2 .OR. STATUSCIUSER) .E. 3 
WHENEVER LEV .G. LEVEL(IUSER) 
EXECUTE DELQUE.(USR) 
TRANSFER TO COMAND 
END OF CONDTIONAL 
OTHERWISE 
LEVELCIUSER) = LEV 
EXECUTE ENDQUE.(USR) 
TIMLEV(IUSER) = 0 
WATTIMCIUSER) = GETOTL.(0) 
END OF CONDITIONAL 
STATUSCIUSER) = 3 
TRANSFER TO DECIDE 
R 
R.. ‘EVENT’ .E,. 10, IS 'NEWUSR' STILL RUNABLE 
WHENEVER STATUS(I.(NEWUSR)) .E. 2 
1 eOR, STATUSCI.C(NEWUSR)) .E. 3, TRANSFER TO RETURN 
SWAP = 0B 
TRANSFER TO DECIDE 
R 
R.. THE NEXT THREE EVENTS ALWAYS OCCUR IN SEQUENCE 
Ree WHEN CONTROL IS TRANSFERRED FROM 'OLDUSR’ TO ‘NEWUSR‘ 
Re. AS A RESULT OF 'SWAP' BEING SET NON-ZERO. 
R.. 'OLDUSR' DOES NOT PAY FOR HIS DUMP, UNLESS 
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EVNT(3) 


EVNT(4) 


EVNT(5) 
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Ree "NEWUSR' 1S OF EQUAL OR LOWER PRIORITY. 
R.» "NEWUSR' ALWAYS PAYS FOR BEING RESTORED EXCEPT 
Ree BACKGROUND NEVER PAYS FOR DUMP-OR RESTORE. 
R 
R.. ‘EVENTS .E. 3, SAVING OF ‘USR'C('IUSER') IS BEGINNING 
Ree EVENT 3 MAY BE CALLED FOR ANY OF THE FOLLOWING: 
R 1. FREEING UP CORE B BECAUSE ‘CURUSR' EXTENDED SIZE 
R 2. FREEING UP CORE A DRUM BUFFERS FOR SWAPPING 
R 3. OUMPING 'OLDUSR' 
R &. DUMPING OTHER USERS TO MAKE ROOM FOR 'NEWUSR' 
BOOLEAN SWPSW, FIRST3, DMPOLD, SWAP 
WHENEVER SWPSW 
WHENEVER FIRSTS 
FIRSTS = OB 
EXECUTE CHARGE.(CPAYUSR, DELTIM, (PAYTIM)) 
WHENEVER LEVEL(E.(NEWUSR)) .GE, LEVEL(!.(OLDUSR)) 
1 AND. OLDUSR .NE. 0 .OR, NEWUSR .E. 0 
PAYUSR = OLDUSR 
OTHERWISE 
PAYUSR = NEWUSR 
END OF CONDITIONAL 
TIMLEV(1.(COLDUSR)) = TIMLEV(I.COLDUSR)) + DELTIM.(LEVTIM) 
OTHERWISE 
EXECUTE CHRGSW. 
WHENEVER USR .E. OLDUSR 
DMPOLD = 1B 
OR WHENEVER DMPOLD .AND. USR .NE. OLDUSR 
1 eAND. NEWUSR .NE. 0 
PAYUSR = NEWUSR 
END OF CONDITIONAL 
END OF CONDITIONAL 
END OF CONDITIONAL 
TRANSFER TO CHANGE 
R 
R.. 'EVENT' .E. &, RESTORING OF '"NEWUSR’ IS BEGINNING 
EXECUTE CHRGSW, 
WHENEVER NEWUSR .E. 0 
PAYUSR = OLDUSR 
OTHERWISE 
PAYUSR = NEWUSR 
END OF CONDITIONAL 
WHENEVER STATUSC(1.(OLDUSR)) .E. 2, 
1 WATTIMC(E.COLDUSR)) = GETOTL.(6) 
CURUSR = NEWUSR 
TRANSFER TO CHANGE 
R 
R.. 'EVENT' .E. 5, "NEWUSR' BEGINS RUNNING AFTER RESTORE 
EXECUTE CHARGE.(CPAYUSR, DELTIM.( PAYTIM)) 
PAYUSR = NEWUSR 
WHENEVER STATUS(I.CNEWUSR)) .E. 3, STATUSCI.(NEWUSR)) = 2 
BEGTIM = GETOTL.(0) 
LEVTIM = BEGTIM 
MAXTIM = BEGTIM + TRUN,(NEWUSR, LEVEL(1.(NEWUSR))) 
1 -TIMLEV(I. (NEWUSR) ) 
SWAP = 08 
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FIRST3 = 1B 
OMPOLD = 0B 
TRANSFER TO DECIDE 
R 
Ree "USR'C'TUSER') ENTERED INPUT WAIT 
STAT(4) WHENEVER STATUSC(IUSER) .E. 2 
EXECUTE DELQUE.(USR) 
STATUSCIUSER) = 4 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 


R 
Ree ‘USR'(TIUSER') TO BEGIN WORKING AFTER 1/0 WAITING 
Ru. OR ALARM CLOCK RETURN FROM DORMANT TO WORKING 
STAT(2) WHENEVER STATUS(IUSER) .GE. 4 .OR. STATUS(IUSER) .E. 1 
WHENEVER STATUS(IUSER) .NE. 1 
WHENEVER LEVEL(IUSER) ~ LEVINC .GE. MINLVL, 
1 LEVEL(IUSER) = LEVEL(TUSER) - LEVINC 
LEV = LEVELF.(LENGTH(IUSER) ) 
WHENEVER LEV .L. LEVEL(IUSER), LEVELC(IUSER) = LEV 
TIMLEV(IUSER) = 0 
END OF CONDITIONAL 
EXECUTE ENDQUE.(USR) 
WATTIMCLUSER) = GETOTL.(0) 
STATUSCIUSER) = 2 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 
R 
R, "USR'C'IUSER") ENTERED OUTPUT WAIT 
STAT(5) WHENEVER STATUSC(IUSER) .E. 2 
EXECUTE DELQUE.(USR) 
STATUSCIUSER) = 5 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 


R 
Ree "USR'C'IUSER') WENT DORMANT WHILE RUNNING 


R. OR PUSHED QUIT BUTTON 


STAT(1) EXECUTE DELQUE.CUSR) 


STATUSCIUSER) = 1 
WHENEVER USR .E. CURUSR, TRANSFER TO DECIDE 


TRANSFER TO CHANGE 
R 


R. "USR'C'IUSER') WENT DEAD, EVENT 6 WILL NOT OCCUR 


STAT(O) EXECUTE DELQUE.(USR) 
STATUSC(IUSER) = 0 
TRANSFER TO DECIDE 

R 


R.. ‘EVENT’ .E. 7, OPERATOR SET KEYS TO "ARG' 


EVNT(7) KEYS = ARG 
BACKGR = ARG 
TRANSFER TO DECIDE 
R 


Rw. ‘EVENT! .E. 8, 'USR'('IUSER') LOGGED IN PROPERLY 


EVNT(8) 


EVNT(9) 


EVNT(11) 


DECIDE 


CHANGE 
RETURN 
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LINMUL(CTUSER) = ARG 
EXECUTE INTIM.(USR) 
TRANSFER TO CHANGE 
R 
R.. ‘EVENT’ .E. 9, 'USR'('IUSER') LOGGED OUT 
EXECUTE OUTTIM.(USR) 
TRANSFER TO CHANGE 
R 
R,. ‘EVENT’ .E. 11, ‘USR'C('IUSER') DIALED UP COMPUTER 
WATTIMCIUSER) = GETOTL.(0) 
NOTIMECIUSER) = 0 
TRANSFER TO CHANGE 
R 
R.. COMMON EXIT FROM SCHED, 
R.. DECIDE IF IT !S TIME TO RUN A NEW USER 


R 
Ree NO DECISION WHILE SWAPPING 
WHENEVER SWAP, TRANSFER TO MONITR 
R 

R 


ee CHECK IF BACKGROUND NOT MEETING GUARANTEED PERCENTAGE 
WHENEVER BKGTIM .L. (PB/100.) * GETOTL.(0) 
1 »AND, CURUSR .NE. 0, BACKGR = 1 
U = HEDUSR.(0) 
WHENEVER BACKGR .NE. O .OR. KEYS .NE. 0, U=O 
R 
Rae RUN USER 'U' IF 'CURUSR' HAS RUN AS LONG AS 'U' WOULD 
WHENEVER U .NE. CURUSR .AND,. 
1 (PREMPT.(TRUN.(U, LEVELC(I.(U)))) .OR. CURUSR .£, 0) 
2 »OR, STATUS(1.(CURUSR)) «NE. 2 .OR. BACKGR .NE. 0 
MONITR = CHANGE 
SWAP = 
NEWUSR 
OLDUSR CURUSR 
BACKGR 0 
END OF CONDITIONAL 
R 
R.. CALL MONSC2, JF COMMON CHANGED, ELSE JUST RETURN 
TRANSFER TO MONITR 
EXECUTE MONSC2, 
EXECUTE PLOT2. 
FUNCTION RETURN 


uiae 
c 


« INTERNAL FUNCTIONS 
. ‘TRUN' - COMPUTES RUN TIME FOR USER 'DU' AT LEVEL 'DL' 
NTERNAL FUNCTION TRUN.(DU, DL) = 

TBASE + LINMUL(!.(DU)) * QUANTM * 2 .P. DL 


anDre RPAnDD 


oe "LEVELF' - COMPUTE PRIORITY LEVEL BASED ON LENGTH ‘LEN' 
INTERNAL .FUNCTIONCLEN) 
ENTRY TO LEVELF. 
WHENEVER LEN .GE. FULLEN 

L = FULLVL 
OTHERWISE 

L = EMPLVL + ILOG2.(LEN/(FULLEN/(2 .P. C(FULLVL“EMPLVL)))) 
END OF CONDITIONAL 
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FUNCTION RETURN L 
END OF FUNCTION 


R 
Ree *PREMPT' - !S TRUE IF PREMPTION IS PERMITTED 
Ree BASED ON TIME INTERRUPTER WILL RUN 'INTRUN' 


BOOLEAN PREMPT, 
INTERNAL FUNCTION PREMPT.CINTRUN) = 
1 INTRUN .L. GETOTL.(0) - BEGTIM 
R 
R.. SUBROUTINE TO CHARGE SWAPPING TIME 
Ree FOREGROUND PAYS FOR BACKGROUND SWAP UP TO 3 SECONDS 

INTERNAL FUNCTION 

ENTRY TO CHRG SW. 

TDEL = DELTIM.(PAYTIM) 

WHENEVER OLDUSR .E. 0 .AND. TDEL .G. BGMAX 
EXECUTE CHARGE.(PAYUSR, BGMAX) 
EXECUTE CHARGE.(0, TDEL-BGMAX) 

OTHERWISE 
EXECUTE CHARGE.(PAYUSR, TDEL) 

END OF CONDITIONAL 

FUNCTION RETURN 

END OF FUNCTION 

R 

R 
INSERT FILE COMN1A 
END OF FUNCTION 
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APPENDIX B - ADDITIONAL CTSS DATA 


This appendix contains statistics describing console 
input-output and the internal states of users as well 
as the relative usage of the CTSS Commands. 

Table 2 shows the measured steady-state probabilities 
of a user console state (idle, input, or output) and of 
the internal states (Dead or Dormant, Working or Command, 
Wait, Input Wait, and Output Wait). For example, the 
probability of finding a user's console idle with an 
internal state of Dead or Dormant is .276. The probab- 
ility of an idle console (regardless of internal state) 
is .502 , etc. Table 3 shows the mean occupancy times 
for these states. 

Table 4 gives a list of each of the CTSS console 
commands, separated by task type with the relative usage 


in a sample of 110,050 commands. 


Internal 
State 


Dead or Working or Input 
Command Wait | Wait 


TABLE 2 - Steady-State Probabilities 


*TET 


TABLE 3 - Mean Occupancy Times (seconds) 


*ZeT 


Table 4: RELATIVE FREQUENCY OF COMMAND USAGE 


Commands of Type 1 Commands of Type 2 Commands of Type 3 Commands of Type 4 


(File Manipulation) (Program Input and (Program Running (Compilation and 
Editing ) and Debugging) Assembly ) 

ARCHIV O17 CTEST9 O01 CTEST1 2001 CTEST2 O11 
CHMODE .018 REVISE ~000 CTEST3 006 CTEST6 .001 
COMBIN O11 INPUT ~O10 CTEST4 .002 CTESTS ~000 
COMFIL .018 EDIT O40 FAPDBG ~005 DYNAMO puolens 
CRUNCH 016 FILE O45 LOADGO 031 MADTRN .010 
CTEST5 ~000 ED Oks MADBUG ~OOL BEFAP 000 
CTEST7 » 000 TFILE .002 NCLOAD 003 BLODI ~000 
DELETE 060 OCTPAT ~001 COMIT ~000 
EX TBSS ~O01 Total 142 OCTTRA ~000 GPSS 000 
PRINTF 060 RESTOR 003 LISP -002 
REMARK - 000 LDABS «000 AED 002 
RENAME O14 OCTLK 008 FAP ~013 
RQUEST -O1L7 PATCH 000 MAD 037 
LISTF 058 LOAD ~009 OPL .000 
PRBIN 002 PM 006 SNOBOL ~O01 
PRBSS ~00 TRA ~000 

PRINT -O1 USE 003 Total 086 

COPY .021 START .029 

LOG «000 VLOAD 2005 Commands of e5 
SPLIT ,.002 STOPAT ,.000 (Miscellaneous 
UPDATE -010 STRACE ~OO1 CENCOM .000 
UPDBSS =. 004 MODIFY  .001 
Total = .114 7187 (includes R) 

Total 349 RESUME : ui 


RUNCOM 009 
RUNOFF -008 


DITTO ~001 
Note: LOGIN, LOGOUT, etc. were not included MEMO ~000 
in these counts and account for .030 of the sD . 004 
usage. SP ~ 000 
SAVE 060 


TYPSET ~009 
Total .278 


“eT 
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APPENDIX C - THE SIMULATION PROGRAMMING SYSTEM 


This section describes a means for preparing and 
running programs to simulate digital computer systems. 
A language, based on the Michigan Algorithm Decoder (MAD, 
see ARDEN, 1963) and scheme for organizing such programs 
is presented. The simulation language is based both on 
the way digital systems are organized and on the methods 
a designer uses to specify such a system. The organiza- 
tion of the operating system for & simlation is. explained 
and the specific implementations are discussed. Finally, 
this similation programming system is compared to several 
other widely used ones. Examples and inforination required 


to use the system are also presented. 
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l. Organization of a Simulation 


The design of a large digital computer system is 
generally divided into several parts. For example, the 
memory system is usually not designed by the same people 
who design the instruction processing unit or the input/ 
output channels and devices. Moreover, the software and 
environment aspects fall into completely different pro- 
vinces. Therefore, it is felt that this same modularity 
should be preserved in the specification of a simulation 
of such a system. Such an organization would have several 
advantages: (1) different people could independently 
specify the simulation programs for their modules, needing 
to work together only to the extent that the original de- 
signers did (ideally, the designer of the module could 
also write the simulation program) ; (2) a change in the 
internal operation of one of the modules or elements in 
the simulation would not disturb the rest; (3) the tradi- 
tional, well-known organization of a digital computer sys- 
tem can be maintained thereby increasing the understanda- 
bility of the simulation program; etc. 

‘The place of the software parts of the system is clear 
in simulations with great detail: the programs are simply 
loaded into the memory simulation element and executed. 
However, in a less detailed simulation, the software func- 


tions can either be distributed among the various hardware 
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elements or, more naturally, be lumped into the control 
section of the simulated system. 

The specification of a program to simulate a large 
system is now reduced to the specification of the elements 
which comprise the system. Two factors must be defined 
in this specification: the series of events occurring 
within the element and the timing of these events with 
respect to events occurring in the remainder of the sys- 
tem. Note that this problem is identical to the one faced 
by the original system designer. 

The implementation of this element specification as 
a module in a simulation program should involve nothing 
more than expressing the series of events and their timing 
in some convenient notation. Since most events within 
elements of a computer system require some computation, 
an algebraic programming language such as FORTRAN, MAD, 
etc. is sufficiently well-known and convenient to provide 
this capability. Communications with other elements with- 
in an event could be accomplished by "sending" outputs 
from one element to another. Timing, then, depends on 
the occurrence of inputs, fixed time increments, variable 
increments and combinations of these. The element speci- 
fication language to be developed incorporates communica- 
tions with other elements and the definition of timing 


with a conventional algebraic language in a natural way. 
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Translation in this language from the timing charts and 
flow diagrams of the hardware designer should thén be as 
natural as that from software flow diagrams to an alge- 
praic language. 

Looking at the simulation structure from an overall 
view, a digital system will be represented by a number of 
programs, one for each element of the system. Since the 
real elements operate simultaneously, their programs 
should at least appear to run simultaneously. Thus, ele- 
ment specifications can be written as if they will be 
operating in parallel with the rest of the system, there- 
by preserving the organizational relationships of the 
original system. 

The element specification language itself is an 
augmented version of MAD. It includes all of the MAD 
declarations and statements plus additional statements for 
defining timing and communication. The translation to 
machine language is accomplished by a pre-processor and 
the normal MAD compiler. Element specifications become 
relocatable subroutines (in the usual sense). The system 
is implemented for use on both CTSS and normally batch- 
processed IBM 7090's. 


138. 
2. System Variables 


One of the factors of an element specification is 
the definition of its interconnection with other elements. 
For this purpose a special type of variable is introduced, 
the "system variable". As in real digital systems, ele- 
ments may have inputs and outputs, an output originating 
from a Single element and fanning out to one or more others. 
System variables must be referred to by the same name wher- 
ever they are used and must be declared as either input 
or output system variables by each element specification 
in which they appear. Two statements are provided for 


the declaration of system variables: 


OUTPUT VARIABLES ‘list! (1) 
INPUT VARIABLES 'list! (2) 


where 'list' is a list of MAD variable names separated 
by commas. The mode (i.e., floating-point, integer, etc.) 
of a system variable may be declared at the programmer's 
option; however, it should be the same mode in all ele- 
ments. A system variable may be an array; but if it is 
multidimensional, it must have the same dimension vector 
in every element in which it occurs. 

There are no restrictions on the naming of system 
variables other than those of the MAD compiler. Input 


system variables must not appear on the left side of a 
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substitution statement. Moreover, no system variable can 
be declared as an output of more than one element. In 
operation, whenever a MAD substitution statement having 
an output variable on the left side is executed, the new 
value is instantaneously transmitted to the elements 


where this system variable is an input. 
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3. Timing of Events 


As was previously stated, an event consists of 
communication, next event selection, and normal computa- 
tion. By use of the system variable declarations and 
the statement repetoire of MAD these functions can be 
accomplished. 

Timing may be specified in two different types of 
statement. In every case, the last statement of one 
event and the first statement of the next are separated 
by a timing statement. First, the time between events 
may depend on the state of the element at the beginning 
of this delay. Such delays can be specified by either: 


DELAY OF ‘expression! (3) 
WAIT UNTIL ‘expression! (4) 


where ‘expression! may be any legal MAD arithmetic ex- 
pression. A statement of type (3) causes a delay between 
events equal to the value of 'expression'. The type (4+) 
statement causes a delay between events such that the 
event occurs when the value of simulation "time" reaches 
the value of 'expression'. Thus, simulation time is in- 
cremented by the value of the delay as the delay statement 
is executed. Moreover, the state of the remainder of the 


elements in the simulation is brought "up to date" during 
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this execution. 
Alternately, the delay between events can depend on 
the time of the arrival of inputs from other elements. 


Such delays are specified by the following statement: 
WAIT FOR INPUT (5) 


where the delay is equal to the increment necessary to 
bring the simulation time up to the point of the next in- 
put from another element. In dealing with elements which 
have many inputs from various sources, the following state- 
ments are useful: 
WAIT FOR INPUT $'input variable name'$ (6) 
WAIT FOR INPUT FROM $'element name'$ (7) 
Statement type (6) causes a delay until the specified 
input variable is sent, type (7), until an input origin- 
ates from the specified element. Neither (6) nor (7) 
have been implemented in the present system, but experience 
has indicated that they would be useful if available. 
Timing can be specified by combinations of the two basic 


types of delay statements. For example, 
WAIT FOR INPUT OR UNTIL 'expression' (8) 


causes a delay until the time of the next input or until 
the point where simulation time reaches the value of 
'expression'!, whichever occurs first. The statement 


WAIT FOR INPUT AND UNTIL 'expression' (9) 
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causes a delay until the time of the next input or until 
the point where time equals ‘expression', whichever occurs 
last. Similarly, the following statements are also allow- 
ed: 
WAIT FOR INPUT OR DELAY OF ‘expression! (10) 
WAIT FOR INPUT AND DELAY OF ‘expression! (11) 
and their use is similar to that of (8) and (9). 
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4, Element Specification-Form and Restrictions 


The first line (exclusive of comments) of an element 


specification defines the name of the element: 
ELEMENT ‘name! (12) 


where 'name' is any legal MAD variable name. At the start 
of the simulation, time zero, control passes to the state- 
ment just after the element name defining statement (type 
12). Any desired initialization should be placed between 
this point and either the execution of the first delay 
statement or the first appearance of an output variable 
on the left side of a substitution statement. Also, all 
system variable declaration statements (types 1 and 2) 
must occur in this initialization segment and must not 

be placed in such a way as to cause them to be executed 
more than once. The last line of an element specification 
is: 


END OF SPECIFICATION (13) 


All lines following this statement will be ignored. 

In addition, there are two other items of importance. 
Any element specification may refer to a variable named 
"TIME" whose value is always the current value of simula- 
tion time. The mode of TIME must be declared by the pro- 


grammer (or left as normal mode). In any case, this mode 
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(integer or floating-point) must be the same in every 
element in a simulation. Furthermore, care must be 
taken that if the mode of TIME is integer, all expres~ 
sions in the delay statements (types 3 - 11) must be 
integer expressions and not of mixed mode. This restric- 
tion is due to a foible of the MAD compiler. Care should 
be taken that the smallest non-zero time increment used 
in a delay statement with floating-point TIME is never 
so small that it will be truncated when added to TIME. 
For integer time, TIME may go up to a 35 bit number if 
care is taken and up to a 27 bit number in any case. A 
second variable named "INPUT" is available. It is of 
the Boolean mode and its value is "1B" if and only if 
an input was received during the previous delay. That 
is, INPUT is reset to "OB" at the beginning of any de- 
lay and set to "1B" on the arrival of any input. 
Element specifications are compiled in the form of 

MAD external functions. Internal functions containing 
delays, etc. may be used; but outside of an internal 
function definition, no use should be made of the follow- 
ing MAD statements: 

FUNCTION RETURN 

ENTRY TO 'name', 

END OF FUNCTION 

END OF PROGRAM 
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Furthermore, should control pass to the 'END OF SPECIFI- 
CATION! statement or to a FUNCTION RETURN, the simiation 
will immediately stop. 

Diagnostic printouts from either the MAD pre-pro- 
cessing program, the MAD compiler, or the simulation op- 
erating system will occur in the event that an error occurs. 
Most of the restrictions are covered in this way. 

A final area of trouble is the use of output variable 
setting substitution statements as the last statement in 
a "THROUGH" loop. The exact reason for this problem is 
easily solved by making the last statement in such loops 
"CONTINUE". 
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5. Examples of Element Specification 


The following are three examples of element specifi- 
cation. They are fairly simple but serve to illustrate 


some of the features of the simulation language. 


1. Oscillator 
This element will have no inputs and a Boolean out- 


put named "TRIG" which oscillates with a period of 10. 


ELEMENT OSC first line. 
OUTPUT VARIABLES TRIG initialization. 
TRIG = OB initialize TRIG. 

L DELAY OF 5. want half the period. 
TRIG = .NOT.TRIG change output. 
TRANSFER TO L contimue. 

BOOLEAN TRIG mode declaration. 
END OF SPECIFICATION last line. 


TIME, in the above element, is floating-point. 


2. Gated Oscillator 

This element is the same as in Example 1, except 
that it has a Boolean input, GATE, which, when 1B causes 
the oscillator to start. When GATE is reset to OB , 
the oscillator will immediately stop and its output re- 
turn to zero. 

ELEMENT GATOSC 

INPUT VARIABLES GATE initialization 


OUTPUT VARIABLES TRIG 
Ll TRIG = OB 


Le WAIT FOR INPUT wait for GATE to come up 


WHENEVER .NOT.GATE, TRANSFER TO L2 


L3 WAIT FOR INPUT OR DELAY OF 5. wait half period or for 


WHENEVER INPUT, TRANSFER TO Ll GATE to come down. 
TRIG = .NOT.TRIG change output. 
TRANSFER TO L3 continue. 

BOOLEAN TRIG, GATE 

END OF SPECIFICATION 
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The simplifying assumption is made that after GATE comes 
up the only input arriving will be GATE coming down. No- 
tice that if the "OR" of the compound delay at L3 were 
made an “AND" the current output pulse would always be 


finished completely before the oscillator turned off. 


3. Memory 
The following element specification will simulate 
@ 1000 word memory with an access time of 2 units. 
Assuming three inputs: 
ADDR -the memory address being referred to. 
MEMIN -the word to be stored by the memory. 
MEMGO -the "go" signal. Its value is zero for no 
action, positive to write and negative to 
read. When it changes to non-zero, the 
other inputs are assumed to be set up. 
and two outputs: 
MEMOUT -the word being read out by the memory. 


MEMRDY -the ready signal from the memory. It 
is non-zero when ready. 


The element specification is: 
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ELEMENT MEM 
OUTPUT VARIABLES MEMOUT, MEMRDY initialization. 
INPUT VARIABLES ADDR, MEMIN, MEMGO 


MEMRDY = 1B send fact that memory is ready. 

Ll WAIT FOR INPUT wait for the "go" signal. 
WHENEVER MEMGO.E.0O,TRANSFER TO L1 if "go" zero, resume waiting. 
MEMRDY = OB turn off r 
DELAY OF 2 wait access time. 

WHENEVER MEMGO.G.O 

CONT(ADDR) = MEMIN if writing,put new contents in. 
OTHERWISE 

MEMOUT = CONT (ADDR) if reading,output requested cell. 
END OF CONDITIONAL 
MEMRDY = 1B send ready signal. 

I2 WAIT FOR INPUT interlock. Reception of ready 
WHENEVER MEMGO.NE.O,TRANSFER TO L2 should cause go to drop. 
TRANSFER TO Ll go back and wait for the 

R next service request. 
R remark card. 


NORMAL MODE IS INTEGER 
BOOLEAN MEMRDY 

DIMENSION CONT(1000) dimension of memory size. 
END OF SPECIFICATION 


Notice that if the "go" signal were to come up again 
immediately after the interlock, continuous memory opera- 
tion would result. In this case the ready signal will stay 
up for zero time. This is sufficient because of the inter- 
lock. TIME is used as an integer variable in this element. 

The problem of interlocking signals is sometimes 
complex both in real and simulated systems. To insure 
that an output is received at more than one place it is 
usually most convenient to have this output hold its value 
for a finite length of time (perhaps 1 unit). Interlock 
techniques are usually a matter of taste and several differ- 


ent schemes are used in the element specifications shown. 
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6. The Simlation Operating System 


The simulation operating system is a group of 
programs which cause the element specification programs 
to appear as if they are being simultaneously executed. 
Since events occur in instants of time, the only real 
problem is with simultaneous events. Events not occurr- 
ing at the same time are simply queued in the order of 
their occurrence and sequentially executed. Events set 
to occur simultaneously are executed in an arbitrary, 
but not random, order. 

Basically the operation of the system is as follows 
(let n be the number of elements in the system): 


1. Let. j=1, let TIME=0. 


2. Enter the jth element at its entry point 
(just after the "ELEMENT 'name'" statement. 


3. Control returns to the operating system via 

a a system variable declaration statement. 
The name and location of the variable is 
added to the proper list and control is 
returned to the element at the point from 
which it came. 

b. a delay statement. The time for the next 
event, for this element, as specified by 


the delay statement, is placed in a list 
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of next-event times. If the element is 
waiting for an input, a notation is made. 
The location of the delay statement is 
recorded. The next operation is step 4. 
ce. an output being sent error, the simulation 
is stopped. (At least one delay must pre- 
cede the first "send". This is taken care 


of by the translator.) 


Let j= j+l, if j is less than n, go to 
step 2. 


The list of next-event times is scanned for the 
lowest time. In case of duplicates, the first 

is used. If all elements are waiting for inputs, 
the simulation is stopped. TIME is incremented 
to the value of this nearest event. In case TIME 
is greater than this value, no change is made; 
i.e., a negative delay is made a zero delay. 
Control is now transferred to the point of the 
last delay in the element corresponding to this 


nearest event. 


Control is returned to the operating system via 
a. a system variable declaration statement 
or a FUNCTION RETURN--error, simulation 


is stopped. 
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be. @ delay statement. The time for the 
next event for this element, as specified 
by the delay statement, is placed in a 
list of next-event times. Notations are 
made of the location of the delay state- 
ment, the type of delay, etc. The next 
operation is step 5. 

Ce. an output being sent. Checks are made to 
determine that this is a valid "send". A 
linear subscript is computed by taking 
the difference between the location origin- 
ally declared and the location being sent. 
If the variable is not subscripted, the 
linear subscript will be zero. The new 
value for the variable is sent to all ele- 
ments.where it is an input using the linear 
subscript. The status of any waiting ele- 
ment receiving an input is appropriately 
changed. Control returns to the element 
at the point from which it came. 


The simulation operating program has the following entry 
points: 
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MAINS9 -original entry to begin simulation. 

IN9999 -entry to declare input variables. 

OUT999_~«sés«-eentry to declare input variable. 

DELAY9 -Simple delay entry. 

WAIT99 -simple "wait for input" entry. 

wvD999 s- -""wait or delay" entry. 

WAD999 ss "wait and delay" entry. 

TIME99 -entry to return the value of TIME in the 
accumulator (for routines other than element 
specifications). 

RESTRT -entry to restart the simulation at time zero. 

TRACER -entry to start the diagnostic trace.(see below) 

STOPTR -entry to stop the diagnostic trace. (see below) 

PRSTAT -entry to print out the status of the simulation. 


(see below) 


Two features are added as an aid to debugging. First, 
there is an entry which prints the status of the simula- 
tion. This information includes the name, location, value, 
source, and destinations for every system variable as well 
as the name, and status of every element. The status of 
an element is described by the location of the last delay, 
its type, and the time associated with it. This time is 
the value at which the delay is to end or, in the case of 


a simple wait, the value of TIME when it began. This status 
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ean be printed by a call to "PRSTAT" at any point in the 
Simulation except during the initialization period. The 
other debugging feature is the trace routine. The execu- 
tion of every delay statement and the sending of every 
output variable (except those which have no destination) 
is noted by: the name of the element in which the state-~ 
ment occurs, the location of this statement, the current 
value of TIME, and either the type of delay or the name, 
subscript, and value of the system variable being set. A 
trace may be started at any time after initialization and 
then stopped, restarted, etc. 

This simulation programming system has been in almost 
continuous use by the author and some others for approxi- 
mately eighteen months and is free of errors. Aside from 
simulating time-shared systems, use has been made of this 
system for the simulation of a storage system, sequential 


logic circuits, etc. 
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The following pages contain listings of the element 


specifications used in the simulations. 


LO 


LOOP 
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ELEMENT MAIN 


R..MAIN CONTROL ELEMENT FOR CTSS SIMULATION. 

R THIS ELEMENT SUPERVISES THE ENTRY OF PROGRAMS INTO ACTIVE 

R STATUS, CALLS THE SCHEDULING ALGORITHM FOR CLOCKED ENTRIES, 
R PROGRAM STATUS CHANGES,ETC., SUPERVISES DUMPING AND LOADING 
R AND SIGNALS THE CONSOLES. THE VARJABLES USED ARE~- 

R  STATUS....STATUS OF PROGRAM (SAME AS IN SCHED.) 

R  LENGTH....LENGTH OF PROGRAMS 

R INTCYC....NO. OF CYCLES TO END CURRENT INTERACTION, : 
R  SWAPGO....SIGNAL TO STORAGE ALGORITHM TO BEGIN SWAP. VALUE 
R 1S THE SIZE OF THE PROGRAM TO BE SWAPPED. SIGN IS 
R POSITIVE !F PRG ON DRUM, NEG. IF ON DISK. 

R  OLDSTA....STATUS OF PROGRAM BEING DUMPED 

R  NXTUSR....NEXT USER TO BE RUN (NEWUSR) 

R  NEWUSR....NEXT USER TO BE RUN 

R  CURUSR....CURRENT USER 

R OLDUSR....USER BEING DUMPED 

R  GO...066..SIGNAL FROM CONSOLE INDICATING INPUT FINISH. 

R RDY...eeeeSIGNAL TO CONSOLE INDICATING INPUT WAIT CIF 

R NEGATIVE) OR PROGRAM FINISH (CIF POSITIVE). 

R SWPDON....SIGNAL FROM STO. ALG. INDICATING SWAP FINISH 

R  CPUGO.....START SIGNAL FOR CPU. 

R  CPUBSY....BUSY SIGNAL FROM CPU 

R CYCDON....SIGNAL FROM CPU INDICATING NO, OF INSTRUCTIONS 

R EXECUTED. 

R 

R 


21/0 VARIABLES. 
OUTPUT VARIABLES CPUGO,SWAPGO,OLDSTA,NXTUSR,LSTUSR, RDY 
INPUT VARIABLES SWPDON, CPUBSY,GO,CYCDON 
R 
R.eINITIALIZE SCHEDULING ALGORITHM, 
NC=NCONS. (0) 
EXECUTE SCHED.(0) 
EXECUTE SCHED.(6,0,32767) 
NXT EME=T IME 
SWPSW=0 
THROUGH LO, FOR J=1,1,U.G.NC 
RDY (J) =1 
LINMULCI.(J))=1 
R 
R..MAIN TIMING LOOP, 
WAIT FOR INPUT OR UNTIL NXTIME 
R 
R SEE {F TIME FOR A CLOCKED ENTRY TO SCHED, 
WHENEVER TIME.GE.NXTIME 
EXECUTE SCHED.(1) 
NXTIME=STIME+CLKINT 
WHENEVER .NOT.INPUT .AND, SWAP.E.0, TRANSFER TO LOOP 
END OF CONDITIONAL 
R 


Ll 


Lwl 


LW2 


L2 


LW3 


L3 


L5 
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R..CHECK INPUT STATUS OF EACH CONSOLE. 
THROUGH L1, FOR J=1,1,JU.G.NC 
R 
WHENEVER GO(J).NE.0 
WHENEVER STATUS(1.(J)). E.4 
R USER 1S COMING OUT OF INPUT WAIT. 
INTCYC(J) =CYCINT. (J) 
RDY(J) =0 
EXECUTE SCHED. (2,u, 2) 
OR WHENEVER STATUS(1.(J)).LE.1 
R USER JUST FINISHED COMMAND. 
INTCYC(J) =CYCINT. (J) 
EXECUTE SCHED. (6,J,PRGSIZ.(J)) 
RDY(J)=0 
EXECUTE SCHED. (2,J,3) 
END OF CONDITIONAL 
END OF CONDITIONAL 
R 
R..CHECK STATUS OF SWAP, IF GOING ON. 
WHENEVER .NOT.SWPDON, TRANSFER TO L2 
R..SWAP FINISHED, SET SWITCHES, RESTART CPU. 
SWPSW=0 
SWAPGO=0 
WAIT FOR INPUT 
WHENEVER SWPDON, TRANSFER TO LWI1 
WHENEVER CURUSR.E.0, TRANSFER TO L2 
CPUGO=INTCYC(CURUSR) : 
WAIT FOR INPUT 
WHENEVER .NOT.CPUBSY, TRANSFER TO LW2 
TRANSFER TO LOOP 
R 
R..SEE IF SWAP IN PROGRESS. 
WHENEVER SWAP.E.0, TRANSFER TO L5 
WHENEVER SWAPGO.NE.0, TRANSF ER TO LOOP 
SWPSW=1 
WHENEVER OLDUSR.E.0, TRANSFER TO L3 
R..STOP CPU SQ SWAP CAN BEGIN. 
CPUGO=0 
WAIT FOR INPUT 
WHENEVER CPUBSY, TRANSFER TO LW3 
INTCYC(OLDUSR)=INTCYC(OLDUSR) -CYCDON 
WHENEVER INTCYC(OLDUSR).LE.O, INTCYC(OLDUSR)=1 
WHENEVER STATUS (1.(NEWUSR)).E.3 
SWAPGO=-LENGTH(1. (NEWUSR) ) 
OTHERWISE 
SWAPGO=LENGTH (1. (NEWUSR) ) 
END OF CONDITIONAL 
NX TUSR=NEWUSR 
LSTUSR=OLDUSR 
OLDSTA=STATUS(1.(OLDUSR) ) 
TRANSFER TO LOOP 
R 
R..NOT SWAPPING, CHECK CPU. 
WHENEVER CURUSR.E.O .OR. CPUBSY, TRANSFER TO LOOP 
CPUGO=0 


LW4 
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PUBSY=1B 
EQUIVALENCE (CPUBSY,PUBSY ) 
WAIT FOR INPUT 
WHENEVER CPUBSY, TRANSFER TO LW& 
INTCYC(CURUSR) #0 
R 
R..SEE IF PROGRAM GOES DEAD, DORMANT, OR INTO I/O WAIT. 
TEM=CONSTA.(0) 
WHENEVER TEM.E.3 
INTCYC (CURUSR)=CYCINT. (0) 
EXECUTE SCHED. (6,CURUSR, PRGSIZ.(0)) 
OTHE RWISE 
RDY (CURUSR) =T IME 
END OF CONDITIONAL 
EXECUTE SCHED. (2,CURUSR,TEM) 
R..'SWAP' MUST BE SET, BEGIN SWAPPING. 
WHENEVER SWAP.E.0, FUNCTION RETURN 
SWPSW=1 
TRANSFER TO L3 
R 
R 
BOOLEAN CPUBSY,KILL,PUBSY, SWPDON 
DIMENSION GO(50),RDY(50), INTCYC(50) 
NORMAL MODE 1S. INTEGER 
VECTOR VALUES CLKINT=200000 
INSERT FILE COMNIA 
END OF SPECIFICATION 
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ELEMENT STOALG 
R..THIS ROUTINE TAKES CARE OF SWAPPING PROGRAMS, 
R..THE VARIABLES USED ARE-- 
R CORUSR,...LIST OF USER NOS. FOR CORE USERS. 
R COREUB....UPPER BOUND LIST FOR CORE USERS. 
R CORELB,...LOWER BOUND LIST FOR CORE USERS. 
R  NINCOR,...NUMBER OF USERS IN CORE, 
R  MXCORE....MAX!MUM NUMBER OF USERS ALLOWED IN CORE. 
R SWAPGO,....GO SIGNAL TO BEGIN SWAP. VALUE IS 
R +SIZE OF NXTUSR WHEN NXTUSR ON DRUM, 
R 0 FOR NO ACTION. 
R -SIZE OF NXTUSR WHEN NXTUSR ON DISK. 
R  NXTUSR....NO, OF NEXT USER (NEWUSR). 
R XMIT.eeeeeGO SIGNAL TO BULK STORAGE TO XMIT A PROGRAM 
R BETWEEN CORE AND DRUM OR DISK, DEPENDING 
R ON SIGN OF 'XMIT',. 
R  XMTRDY....READY SIGNAL FROM BULK STORAGE. 
R SWPDON,...READY SIGNAL TO MAIN CONTROL. 
R  CONDS.....NO. OF WORDS FOR MACHINE CONDITIONS AND DISK 
R STATUS OF A USER. ALWAYS DUMPED AND LOADED. 
R 
R 


«o1/0 VARIABLES, 
INPUT VARIABLES SWAPGO, OLDSTA,NXTUSR,XMTRDY,LSTUSR 
OUTPUT VARIABLES XMIT, SWPDON 
R sak 
VECTOR VALUES CONDS=714 
Ree INITIALIZATION. 


XMIT=0 
NINCOR=0 
SWPDON=08B 
R 
R..WAIT HERE FOR SWAP GO SIGNAL FROM MAIN CONTROL. 
WAJT WAIT FOR ft. PUT 
WHENEVER SWAPGO.E.0, TRANSFER TO WAIT 
R 


R..DUMP OLD USER, TELL SCHED. ALG. 
EXECUTE SCHED.(3) 
R..1F LAST USER NOT 0, DUMP MACHINE CONDITIONS TO DRUM. 


XMIT=CONDS 

Lw00 WAIT FOR INPUT 
WHENEVER .NOT.XMTRDY, TRANSFER TO Lwoo 
XMIT=0 

LWO1 WAIT FOR INPUT 


WHENEVER XMTRDY, TRANSFER TO LWOL 
WHENEVER OLDSTA.NE.2, TRANSFER TO BIGOMP 
WHENEVER NINCOR. GNBUFF, TRANSFER TO DMPONE 
R 
R.«MAKE ENOUGH ROOM IN CORE FOR NEW USER. 
FREEUP WHENEVER NINCOR.E.0O 
XMIT=SWAPGO 
TRANSFER TO DMPDON 
OR WHENEVER NXTUSR. E.CORUSR(1) 
XMST=CORELB(1) 
TRANSFER TO DMPDON 
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OR WHENEVER .ABS.SWAPGO.LE.CORELB(1) 
XMIT=SWAPGO 
TRANSFER TO DMPDON 

OR WHENEVER .ABS.SWAPGO.L.COREUB(1) 
XMIT=, ABS .SWAPGO-CORELB(1) 


LW1 WAIT FOR INPUT 
WHENEVER .NOT.XMTRDY, TRANSFER TO LW1 
XMIT=0 

LW2 WAIT FOR INPUT 


WHENEVER XMTRDY, TRANSFER TO LW2 
XMIT=SWAPGO 
CORELB(1) =. ABS. SWAPGO 
TRANSFER TO DMPDON 
OTHERWISE 
XMIT=COREUB(1 )-CORELB(1) 
LW3 WAIT FOR INPUT 
WHENEVER .NOT.XMTRDY, TRANSFER TO LW3 
XMIT#=0 
LWh WAIT FOR INPUT 
WHENEVER XMTRDY, TRANSFER TO LW4& 
THROUGH L2, FOR J#1,1,J.GE.NINCOR 
CORUSR(J) =CORUSR(J +1) 
COREUB(J) sCOREUB(J+1) 
L2 CORELB(J )=CORELB(J+1) 
NINCOR=NINCOR~1 
END OF CONDITIONAL 
TRANSFER TO FREEUP 
R 
R.»ALL DUMPING DONE, LOAD HAS JUST STARTED. INFORM 
R. SCHEDULING ALGORITHM AND WAIT FOR COMPLETION. 


DMPDON EXECUTE SCHED. (4) 
LW5 WAIT FOR INPUT 
WHENEVER .NOT.XMTRDY, TRANSFER TO LWS5 
XMIT=0 
LW6 WAIT FOR {INPUT 
WHENEVER XMTRDY, TRANSFER TO LW6 
R 


R..PROG. LOADED, LOAD MACHINE CONDITIONS, ETC. FROM DRUM, 
R.. ALG., GIVE FINISH SIGNAL TO MAIN CONTROL ELEMENT. 


XMIT=CONDS 

LW100 WAIT FOR INPUT 
WHENEVER .NOT.XMTRDY, TRANSFER TO LW100 
XMIT=0 

LW101 WAIT FOR INPUT 


WHENEVER XMTRDY, TRANSFER TO LW101 

EXECUTE SCHED, (5) 

SWPDON=1B 

WHENEVER NINCOR.G.O .AND. NXTUSR.E.CORUSR(1) 
CORELB(1) =0 
TRANSFER TO LW7 

END OF CONDITSONAL 

CORELB(0) =0 

COREUB(0)=.ABS. SWAPGO 

CORUSR(0) =NXTUSR 

NINCOR=N ENCOR+1 


L3 
LW7 


DMPONE 


L4 
LW8 


LW9 


L5 


BIGDMP 
LW10 


LW1l 
DELETE 


L6 


THROUGH L3, FOR J*NINCOR,-1,U.LE.0 
CORELB(J)=CORELB(J-1) 
COREUB(J)=COREUB(J~1) 
CORUSR(J) =CORUSR(J-1) 
WAIT FOR INPUT 
WHENEVER SWAPGO.NE.0, TRANSFER TO LW7 
SWPDON=0B 
TRANSFER TO WAIT 
R 
R 
R..NOQ MORE WRITE BUFFERS, COMPLETE DUMP OF USER 
R..CLOSEST TO BEING COMPLETELY DUMPED. 
JJ=2 
SIZE=COREUB(2)-CORELB(2) 
THROUGH L4&, FOR J=3,1,J.G.NINCOR 
WHENEVER SIZE.G.COREUB(J)-CORELB(u) 
JJeJ 
SIZE=COREUB(J)-CORELB(J) 
END OF CONDITIONAL 
XMITSSIZE 
WAIT FOR INPUT 
WHENEVER .NOT.XMTRDY, TRANSFER TO LW8 
XMIT=0 
WAIT FOR INPUT 
WHENEVER XMTRDY, TRANSFER TO LW9 
THROUGH L5, FOR J=JJ,1,JU.GE.NINCOR 
CORELB (J) =CORELB (J+1) 
COREUB(J) sCOREUB(J+1) 
CORUSR( JU) =CORUSR(J+1) 
NINCOR=N INCOR-1 
TRANSFER TO FREEUP 
R 
R 
R..OLD USER NOT IN WORKING STATUS, DUMP ENTIRELY. 
WHENEVER OLDSTAZ .0, TRANSF R TO DELETE 
XMIT=COREUB(1) 
WAIT FOR INPUT 
WHENEVER .NOT.XMTRDY, TRANSFER TO LW10 
XMIT=0 
WAIT FOR INPUT 
WHENEVER XMTRDY, TRANSFER TO LW11 
THROUGH L6, FOR J#=1,1,J.GE.NINCOR 
CORELB(J) =CORELB(J+1) 
COREUB(J)=COREUB(J+1) 
CORUSR(J ) =CORUSR(J+1) 
NINCOR=NINCOR-1 
TRANSFER TO FREEUP 
R 
R 
NORMAL MODE IS INTEGER 
BOOLEAN SWPRDY, XMTRDY, SWPDON 
DIMENSION CORELB(5) ,COREUB(5),CORUSR(5) 
VECTOR VALUES NBUFF=4 
END OF SPECIFICATION 
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ELEMENT BULK 
R.»THIS ELEMENT SIMULATES BOTH THE DISK AND DRUM. 
R 
R..1/0 VARIABLES. 

INPUT VARIABLES XMIT 

OUTPUT VARIABLES XMTRDY,DSKUSE ,DRMUSE 


R 
DSKUSE=0 
DRMUSE =0 
LOOP XMTRDY=0B 
WAITL WAIT FOR I NUT 


WHENEVER XMIT.E.0, TRANSFER TO WAIT1 
WHENEVER XMIT.G.0 
TEM=DRMDEL .(XMIT) 
DRMUS E=DRMUSE+TEM 
OTHERWISE 
TEM=DSKDEL.(.ABS.XMIT) 
DSKUSE=DSKUSE+TEM 
END OF CONDITIONAL 
DELAY OF TEM 
XMTRDY=1B 
WAIT2 WAIT FOR INPUT 
WHENEVER XMIT.NE.O, TRANSFER TO WAIT2 
TRANSFER TO LOOP 


NORMAL MODE IS INTEGER 
BOOLEAN XMTRDY 
END OF SPECIFICATION 


LOOP 
WAIT1 


WAIT2 


WAITS 


STOP 
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ELEMENT CPU 


R.eTHIS ELEMENT SIMULATES A CPU WITH NO SIGNIFICANT 
R..CHANNEL OPERATION GOING ON WHILE IT 1S OPERATING. 
R 


R..3/0 VARIABLES, 


R 


INPUT VARIABLES CPUGO 
OUTPUT VARIABLES CPUBSY,CYCDON,CPUUSE 


C RUSE=0 

CPUBSY=08 

WAIT FOR INPUT 

WHENEVER QP UGO.E.0, TRANSFER TO WAIT1 

CPUBSY=1B 

STARTT=T IME 

TEM=FTOI.CIUTOF.(CPUGO)/ INRATE.(0)) 

FINTIM=TIME + TEM 

TEM=CPUGO 

WAIT FOR INPUT OR UNTIL FINTIM 

WHENEVER CPUGO.E.0 
CYCDON=(TIME=STARTT) * INRATE.(0) 
WHENEVER CYCDON.GE,TEM, CYCDON=TEM~1 
CPUBSY=0B 
TRANSFER TO STOP 

OR WHENEVER TIME.GE.FINTIM 
CYCDON=TEM 
CPUBSY=0B 
WAIT FOR INPUT 
WHENEVER CPUGO.NE.0, TRANSFER TO WAITS 
TRANSFER TO STOP 

END OF CONDITIONAL 

TRANSFER TO WAIT2 


CPUUSE=CPUUSE+T IME=STARTT 
TRANSFER TO LOOP 


NORMAL MODE IS INTEGER 
FLOATING POINT INRATE.,ITOF. 
BOOLEAN CPUBSY 

END OF SPECIFICATION 


LO 


LOOP 


LwW1 


JOINT 
Ll 


R 
R 


R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 


R 
R 


R 
R 
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ELEMENT CONS 
ee THIS ELEMENT SIMULATES ALL OF THE CONSOLES. 
«THE VARIABLES ARE-- 
GO. ..ee0eeStGNAL TO MAIN CONTROL INDICATING CONSOLE'S 
COMPLETION OF INPUT. 
RDY..2e0eeSIGNAL FROM MAIN CONTROL INDICATING EITHER 
USER'S PROGRAM IS _ IN INPUT WAIT (IF NEG.) OR 
FINISHED (IF POSITIVE). 
NXTACT....LIST OF TIMES FOR CONSOLES TO FINISH INPUT, 
IF ZERO, CONSOLE 1S WAITING FOR PROGRAM, 
NXTIME...-TIME OF NEXT EVENT (CONSOLE FINISHING INPUT). 
NCONS.....NUMBER OF CONSOLES. 


«1/0 VARIABLES. 
INPUT VARIABLES RDY 
OUTPUT VARIABLES GO 
NC=NCONS.(0) 


ee INITIALIZATION, 

DELAY OF 1 

THROUGH LO, FOR [#1,1,1.G.NC 
GO(1)=0 

NXTACT(1)=0 

CONT INUE 


. MAIN LOOP. 
NXTIME=0 
THROUGH L1, FOR 1#1,1,1.G.NC 
WHENEVER NXTACT(1).NE.O 
WHENEVER NXTACT(1).G.TIME, TRANSFER TO JOINT 
GO(1)=TIME 
WAIT FOR INPUT 
WHENEVER GO(1) .NE.TIME 
PRINT FORMAT ERR, TIME 
EXIT. 
V'S ERR=$10HCONS ERR. K12*$ 
END OF CONDITIONAL 
WHENEVER RDY(1).NE.O, TRANSFER TO LW1 
NXTACT(1) #0 
GO(1) =0 
TRANSFER TO L1 
OTHERWISE 
WHENEVER RDY(1).E.0, TRANSFER TO L1 
NXTACT (1) =TIME+INTDEL. (1) 
END OF CONDITIONAL 
WHENEVER NXTIME.G.NXTACT(1).OR.NXTIME.E.0, NXTIME@NXTACT( 1) 
CONTINUE 
WHENEVER NXTIME.E.0 
WAIT FOR INPUT 
OTHERWISE 
WAIT FOR INPUT OR UNTIL NXTIME 
END OF CONDITIONAL 
TRANSFER TO LOOP 


R 


NORMAL MODE IS INTEGER 
DIMENSION RDY(50),G0(50) ,NXTACT(50) 
END OF SPECIFICATION 


164. 


LO 


IDLE 


LOADWT 


LooP 


Lw1 


HOLD 


PUS TOP 


LW2 
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R.. ELEMENT TO CONTROL CPU AND SWAPPING FOR OVERLAPPED 
R.. OPERATION OF DISK, DRUM, AND PROCESSOR, 
R 

ELEMENT CPUCTL 

INPUT VARLABLES STARTU,GO,CPUBSY,CYCDON 

OUTPUT VARIABLES NEEDU,RDY,CPUGO,NEWUSR 

OUTPUT VARIABLES NQ,Q 

NORMAL MODE IS INTEGER 


CPUGO=0 
NUSERS=NCONS.(0) 
THROUGH LO, FOR J=1,1,J.G.NUSERS 
RDY (J) =1 
CONTINUE 
NQ=0 
NEWUSR=0 
NEEDU=1B 
R 
R.. HERE WHEN IDLE, WAIT FOR NEW USER TO COME ALONG. 
WAIT FOR INPUT 
CHECKU. 
WHENEVER NEWUSR.E.0, TRANSFER TO IDLE 
R 
R.. WAIT FOR LOAD OF NEW USER, 
WAIT FOR INPUT 
CHECKU. 
WHENEVER STARTU.NE.NEWUSR, TRANSFER TO LOADWT 
R 
R.. LOAD DONE, INTERLOCK, 
NEEDU=0B 
CPUGO=INTCYC(NEWUSR) 
SWPSW=20 
EXECUTE MONSC1.(5,NEWUSR, 0) 
STATUS (1. (NEWUSR) )=2 
GETNXT. 
WAIT FOR INPUT 
WHENEVER STARTU,NE.O, TRANSFER TO LW1 
WHENEVER .NOT.CPUBSY, TRANSFER TO LW1 
CHECKU. 
R 
R.. HERE WHEN USER STARTED. 
FINTIM=TIME + BURSTT.(0) 
WAIT FOR INPUT OR UNTIL FINTIM 
WHENEVER .NOT.CPUBSY 
R.. CPU STOPPED. FINISH OFF USER. 
CPUGO=0 
PUBSY=1B 
EQUIVALENCE (CPUBSY,PUBSY) 
WAIT FOR INPUT 
WHENEVER CPUBSY, TRANSFER TO LW2 
TEMS TA=CONSTA.(0) 
WHENEVER TEMSTA.NE.3 
RDY (CURUSR) =T IME 
DELQ.(CURUSR) 
END OF CONDITIONAL 
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EXECUTE MONSC1. (2, CURUSR, TEMSTA) 
SWPSW=1 

EXECUTE MONSC1. (3,CURUSR,0) 
STATUS (1. (CURUSR) )=TEMSTA 


NEEDU=1B 
CHECKU, 
WHENEVER NEWUSR.E.0, TRANSFER TO IDLE 
LW3 WHENEVER STARTU.E.NEWUSR, TRANSFER TO LOOP 
CHECKU, 


WAIT FOR INPUT 
TRANSFER TO LW3 
OR WHENEVER TIME.GE.FINTIM 
WHENEVER NEWUSR.NE.O, NEEDU#=18 
LW4 WHENEVER .NOT.CPUBSY, TRANSFER TO PUSTOP 
CHECKU,. 
WHENEVER NEWUSR.NE.O .AND. .NOT.NEEDU 
NEEDU=1B 
END OF CONDITIONAL 
WHENEVER STARTU.NE.O, TRANSFER TO STOPPU 
WAIT FOR INPUT 
TRANSFER TO LW4& 


STOPPU CPUGO=0 

SWPSW=1 

EXECUTE MONSC1.(3,OLOUSR,0) 
LW5 WAIT FOR INPUT 


WHENEVER CPUBSY, TRANSFER TO LW5 
INTCYCCOLDUSR) =INTCYC(OLDUSR) -CYCDON 
WHENEVER INTCYCCOLDUSR).LE.O, INTCYCCOLDUSR)=1 
NEEDU=1B 
LW6 CHECKU. 

WHENEVER NEWUSR.E,.STARTU, TRANSFER TO LOOP 
WAIT FOR INPUT 
TRANSFER TO LW6 

END OF CONDITIONAL 

CHECKU, 

TRANSFER TO HOLD 


BOOLEAN CPUBSY,PUBSY,NEEDU, CHANGE 
DIMENSION GO(50),RDY(50),INTCYC(50),Q(50) 


INTERNAL FUNCTION 
NTRY TO GETNXT. 
CHECKU. 
WHENEVER NQ.E.0 .OR, (NQ.E.1 .AND. CURUSR.NE.O) 
NEWUSR=0 
FUNCTION RETURN 
OR WHENEVER CURUSR.E.0 
NEWUSR=Q(1) 
FUNCTION RETURN 
END OF CONDITIONAL 
THROUGH GETN1, FOR J#1,1,J.G.NQ 
GETN1 WHENEVER Q(J).E.CURUSR, TRANSFER TO GETN2 
PRINT COMMENT $CURRENT USER NOT IN QUEUE.$ 
EXIT. 
GETN2 JaJ+1] 
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WHENEVER J.G.NQ, J=1 
NEWUSR=Q(J) 

FUNCTION RETURN 

END OF FUNCTION 


INTERNAL FUNCTION 

ENTRY TO CHECKU. 

CHANGE=0B 

THROUGH CHECK1, FOR J#1,1,JU.G.NUSERS 

WHENEVER RDY(J).E.0 .OR. GO(J).E.0, TRANSFER TO CHECK1 

WHENEVER STATUS(1.(J)).LE.1 
EXECUTE MONSC1.(2,J,3) 
STATUS (I. (J)) #3 
LENGTHC 1. (J) ) sPRGSIZ. (0) 
MONSC1.(6,J,LENGTH(1.(J))) 

OTHERWISE 
EXECUTE MONSC1.(2,J,2) 
STATUS(1..(J))=2 

END OF CONDITIONAL 

INTCYC(J) =CYCINT. (0) 

RDY(J)=0 

WHENEVER NEWUSR.E.0 
NEWUSR2J 

END OF CONDITIONAL 

NQ=NQ+1 

Q(NQ) =J 

CHANGE=1B 

CHECK1 CONTINUE 

WHENEVER CHANGE, SORTQ. 

FUNCTION RETURN 

END OF FUNCTION 


INTERNAL FUNCTION 

ENTRY TO SORTQ,. 

CHANGE =0B 

THROUGH SORT2, FOR J=1,1,JU.GE.NQ 

THROUGH SORT1, FOR JJ5J+1,1,dJN.G.NQ 

WHENEVER LENGTH(1.(Q(J))).G.LENGTH().(Q(Jd))) 
1 .AND, CHANGE, TRANSFER TO SORTO 

WHENEVER LENGTH(1.(Q(J))) .L.LENGTH(1.(Q(Jd))) 
1 .AND. .NOT.CHANGE, TRANSFER TO SORTO 

TRANSFER TO SORT1 


SORTO TEM=Q(J) 
Q(J)=Q(ud) 
Q(JJ)=TEM 

SORT1 CONTINUE 

SORT2 CHANGE=.NOT. CHANGE 


FUNCTION RETURN 
END OF FUNCTION 


INTERNAL FUNCTION (A) 
ENTRY TO DELQ. 
THROUGH DEL1, FOR J=1,1,J.G.NQ 
DELI WHENEVER Q(J).E.A, TRANSFER TO DEL2 
PRINT COMMENT $USER TO BE DELETED NOT IN QUEUE.$ 
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PRINT FORMAT XX,A,CURUSR, OLDUSR, NEWUSR,NQ,Q(1)...Q(25) 
V'S XX=$4HARG#12,3H CUI3,3H OUI3,3H NUI3,3H NQI3, 
1 /2513*$ 
EXIT. 
DEL2 THROUGH DEL3, FOR J*J+1,1,J.G.NQ 
DEL3 Q(J-1)=Q(J) 
NQ=NQ-1 
sORTQ. 
FUNCTION RETURN 
END OF FUNCTION 


INSERT FILE COMN1A 
END OF SPECIFICATION 


Note that MONSC1 Is a data taking routine called with the 
same arguments that the CTSS Scheduling Algorithm used. 
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R.. SWAP CONTROL FOR OVERLAPPED SWAPPING. 
ELEMENT BLKCTL 
R 
R.. 1/0 VARIABLES. 
OUTPUT VARIABLES OLDUSR,CURUSR 
INPUT VARIABLES NEEDU,NEWUSR, XMTRDY 
OUTPUT VARIABLES STARTU,XMIT 
NORMAL MODE |S INTEGER 
BOOLEAN NEEDU, XMTRDY 
R 
Roe INITEALIZATION, 
STARTU=0 
CURUSR=0 
OLDUSR=0 
XMIT=0 
LSIZE=0 
DSIZE=0 
LENGTH (0)=77776K 
STATUS (0) =2 
VECTOR VALUES STASIZ#714 
R 
R.. HERE WHEN CURRENT USER RUNNING AND NO NEW USER, 
IDLE WAIT FOR §INPUT 
R 
LOOP WHENEVER NEWUSR.NE.O, TRANSFER TO LOAD 
wHENEVER .NOT.NEEDU .OR. CURUSR.E.O, TRANSFER TO IDLE 
R 
R.. DUMP CURRENT USER, NO NEW USER YET. 
OLDUSR=CURUSR 
CURUSR=0 
WHENEVER STATUS(1.(OLDUSR)).E.0 
DSIZE=0 
OTHERWISE 
DSI ZE=SLENGTH( 1. (OLDUSR) ) 
END OF CONDITIONAL 
BULKGO. (DSIZE+STASIZ) 
DSIZE=0 
WHENEVER NEWUSR.NE.O 
CURS1IZ=0 
TRANSFER TO LOAD1 
END OF CONDITIONAL 
BULKGO. (STASIZ+LENGTH (0) ) 
CURUSR=0 
TRANSFER TO LOOP 


R 
R.. LOAD NEW USER WHILE OLD USER RUNNING. 
LOAD CURS 1Z*LENGTH( 1. (CURUSR) ) 
LOAD1 LSIZE=LENGTH(1. (NEWUSR) ) 
WHENEVER LSIZE.G.(77777K=CURSIZ), TRANSFER TO HARDFT 
R 


R.. NEW USER FITS INTO CORE WITH CURRENT USER. 
WHENEVER STATUS(1.(NEWUSR)).E.3 
BULKGO.(STASIZ) 
BULKGO.(-LSIZE) 
OTHERWISE 
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BULKGO, (STASIZ+LSIZE) 
END OF CONDITIONAL 
LSIZE=0 
LW1 WHENEVER NEEDU, TRANSFER TO L1 
WAIT FOR INPUT 
TRANSFER TO LW1 
Li OLDUSR=CURUSR 
STARTU=NEWUSR 
CURUSR=NEWUSR 
LW2 WAIT FOR INPUT 
WHENEVER NEEDU, TRANSFER TO Lw2 
TARTU=0 
HHENEVER STATUS(1.(OLDUSR)).E.0 
DSIZE=0 
OTHERWISE 
OS'ZE=CURSIZ 
END OF COND! TIONAL 
BULKGO, (DSIZE+STASIZ) 
OS! ZE=0 
TRANSFER TO LOOP 
R 
R.. NEW USER WILL NOT FIT INTO CORE WITH CURRENT USER. 
HARDFT LSIZE=CURSIZ+LSIZE-77777K 
WHENEVER STATUS(1.(NEWUSR)).E.3 
BULKGO. (STASIZ) 
BULKGO.(CURS12Z-77777K) 
OTHERWISE 
BULKGO. (STASI Z+77777K-CURSIZ) 
END OF CONDITIONAL 
LW3 WHENEVER NEEDU, TRANSFER TO L2 
WAIT FOR INPUT 
TRANSFER TO LW3 
L2 STARTU=-NEWUSR 
OLDUSR=CURUSR 
WHENEVER STATUS(1.(OLDUSR)).E.0 
DSIZE=0 
BULKGO, (STASIZ) 
OTHERWISE 
BULKGO, (STASIZ+LSIZE) 
DS!ZE=CURSIZ-LSIZE 
END OF CONDITIONAL 
WHENEVER STATUS(1.(NEWUSR)).E.3 
NOSEEK, (1) 
BULKGO.(-LSIZE) 
NOSEEK.(0) 
OTHERWISE 
BULKGO.(LSIZE) 
END OF CONDITIONAL 
LSIZE=0 
STARTU=NEWUSR 
CURUSR=NEWUSR 
LW& WAIT FOR INPUT 
WHENEVER NEEDU, TRANSFER TO LW4 
STARTU=0 
WHENEVER DS!ZE.G.0, BULKGO.(DSIZE) 


Bl 


B2 


R 
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DSIZE=0 
TRANSFER TO LOOP 


R.. INTERNAL FUNCTION TO WORK DISK AND DRUM, 


INTERNAL FUNCTION (ARG) 

ENTRY TO BULKGO, 

XMIT=ARG 

WAIT FOR INPUT 

WHENEVER NEWUSR,.NE.O .AND. CURUSR.E.0 
CURUSR=NEWUSR 

END OF CONDITIONAL 

WHENEVER .NOT.XMTRDY, TRANSFER TO B1 

XM1T#=0 

WAIT FOR {INPUT 

WHENEVER XMTRDY, TRANSFER TO B2 

FUNCTION RETURN 

END OF FUNCTION 


INSERT FILE COMN1A 
END OF SPECIFICATION 


LOOP 
WAITL 


WAIT2 


172. 


Re. THIS ELEMENT SIMULATES BOTH THE DRUM AND THE DISK. 
Ra. ST PROVIDES A FACTOR, ‘IOFACT', TO THE CPU ELEMENT GIVING 
Ro. THE AVERAGE FACTOR OF DEGRADATION BETWEEN 0 AND 1. 


R 


R 


ELEMENT BULK 
INPUT VARIABLES XMIT,CPUBSY 
OUTPUT VARIABLES XMTRDY, IOFACT,DKOUSE,DSKUSE,DMOUSE , DRMUSE 


DSKUSE=0 
DRMUSE=0 
DKOUSE=0 
DMOUSE=0 
XMTRDY=08 
lOFACT=1. 
WAIT FOR L PUT 
WHENEVER XMIT.E.0, TRANSFER TO WAIT1 
WHENEVER XMIT.G.0 
TEM=DRMDEL, (XMIT) 
OFACT=.7 
RMUSE=DRMUSE+TEM . 
WHENEVER CPUBSY, DMOUSE=DMOUSE+TEM 
OTHERWISE 
TEM=DSKDEL.(.ABS.XMIT) 
DSKUSE=DSKUSE+TEM 
IOFACT=.988 
WHENEVER CPUBSY, DKOUSE=DKOUSE+TEM 
END OF CONDITIONAL 
DELAY OF TEM 
XMTRDY=1B 
WAIT FOR INPUT 
WHENEVER XMIT.NE.O, TRANSFER TO WAI T2 
TRANSFER TO LOOP 


FLOATING POINT IOFACT 
NORMAL MODE IS INTEGER 
BOOLEAN XMTRDY,CPUBSY 
END OF SPECIFICATION 
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R.. GPU FOR OVERLAPPED CPU AND BULK MEMORY OPERATION. 
Re. SAME AS OLD CPU ELEMENT, EXCEPT THAT 'IOFACT’ GIVES 
R.. FACTOR OF SLOWDOWN BECAUSE OF OVERLAP. 
R 
ELEMENT CPU 
INPUT VARIABLES CPUGO, IOFACT 
OUTPUT VARIABLES C PUBSY,CYCDON, PUUSE ,NPUUSE 
GPUUSE=0 
NPUUSE =0 
R 
LOOP C PUBSY=0B 
WAIT1 WAIT FOR INPUT 
“WHENEVER CPUGO.E.0, TRANSFER TO WAIT 
CPUBSY=18 
CYCDON=0 
PUGO=CPUGO 
R 


AGAIN FINTIM=TIME+FTOS.CITOF. (CPUGO-CYCDON)/CINRATE.(0)*!O0FACT) ) 
FACTSIOFACT 
STARTT#T IME 
WAIT2 WAIT FOR INPUT OR UNTIL FINTIM 
WHENEVER CPUGO.E.0 .OR. !OFACT.NE.FACT 
CYCDON=CYCDON+FTOI.CI TOF. (TIME-STARTT) ®1NRATE. (0)*FACT) 
GPUUSE =GPUUSE+T IME-STARTT 
NPUUSE=NPUUSE+FTO!.(FACT*I TOF. (TIME~STARTT)) 
WHENEVER CYCDON.GE.PUGO 
CYCDON=PUGO 
STARTT=TIME 
WHENEVER CPUGO.LE.0, TRANSFER TO STOP 
END OF CONDITIONAL 
WHENEVER CPUGO.NE.0, TRANSFER TO AGAIN 
CPUBSY=0B 
TRANSFER TO LOOP 
OR WHENEVER TIME.GE.FINTIM 
STOP CYCDON=PUGO 
GPUBSY=GPUBSY+T IME+STARTT 
NPUBSY=NPUBSY+FTOI.(FACT#I TOF. (TIME=STARTT)) 
CPUBSY=0B 
WAITS WAIT FOR INPUT 
WHENEVER CPUGOL E.0, TRANSFER TO WAIT3 
TRANSFER TO LOOP 
END OF CONDITIONAL 
TRANSFER TO WAIT2 


NORMAL MODE IS INTEGER 

FLOATING POINT ITOF.,INRATE., 1OFACT, FACT 
BOOLEAN CPUBSY 

END OF SPECIFICATION 


Ll 
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This program provides random numbers of various types, etc. 


EXTERNAL FUNCTION (ARG) 
INTEGER ARG 
ENTRY TO BURST. 

R ENTRY TO GIVE BURST TIME IN 1/60THS. 
FUNCTION RETURN 120 

R 

R 
ENTRY TO BURSTT. 

R GIVES QUANTUM TIME. 

FUNCTION RETURN 2 000 000 
ENTRY TO NCONS. 

R GIVES NUMBER OF CONSOLES... 
FUNCTION RETURN 35 
ENTRY TO PRGSIZ. 

R RETURNS PROGRAM SIZES ACCORDING TO FOLLOWING DISTRIBUTION, 
VECTOR VALUES SIZDIS = .155, 

1.045, .27, .03, .05, .03, .02, .0725, .015, .01, .035, 
.025, .015, .005, .0025, .01, .01, .01, .005, .0025, .005, 
.005, .01, .005, .00, .0025, .00, .005, .00, .005, .00, 
.005, .005, .005, .005, .00, .00, .00, .0025, .00, .005, 
.005, .0075, .00, .00, .00, .00, .00, .00, .005, .005, 
-005, .005, .005, .00, .00, .00, .00, .00, .00, .015, 
-0025, .00, .005, .0125, .04501 
LAST ENTRY IS .00001 TOO HIGH TO INSURE WORKING, 

X=RANNO,. (0) 

TOT#=0. 

THROUGH L1, FOR 1=0.,1.,TOT.GE.X 

TOTSTOT+SIZDIS(1) 

INT=(1+TOT-X) #500, 

WHENEVER INT.G.32766., 1NT=32766. 

TRANSFER TO RETURN 

R 
ENTRY TO CONSTA. 

R RETURNS THE NEW STATE FOR A PROGRAM. VALUE IS 

R EITHER 0,1,3, OR 4. 

TOT=RANNO. (0) 

WHENEVER TOT.LE..631, FUNCTION RETURN & 
WHENEVER TOT.LE..812, FUNCTION RETURN 0 
WHENEVER TOT.LE..88, FUNCTION RETURN 1 
FUNCTION RETURN 3 

R 
ENTRY TO INRATE. 

R ARBITRARY RATE OF INSTRUCTION EXECUTION. 

FUNCTION RETURN .2 

R NO. OF INSTRUCTIONS EXECUTED FOR AN INTERACTION. 
R.. VALUES FOR CPU TIME DISTRIBUTION. 

VECTOR VALUES CPU= 

1.5072, .04K9, .0609, .0393, .0363, 

2 .0304, .0248, .0250, .0217, .0186, 

3.0148, .0119, .0100, .0090, .0085, 

4 .0076, .0070, .0065, .0058, .0053, .0052 
ENTRY TO INTCYC, 

ENTRY TO CYCINT. 
X=RANNO, (0) 


BNW EWP 


LL 
LLL 
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WHENEVER X.G..99 
CPUT=5. + 24.7%(-L0G.(1.-RANNO.(0))) 
OR WHENEVER X.G..97 
CPUT#&, + RANNO.(0) 
OR WHENEVER X,.G..94 
CPUT=3, + RANNO.(0) 
OR WHENEVER X.G..895 
CPUT=2. + RANNO.(0) 
OTHERWISE 
TOT=0. 
THROUGH LL, FOR 1=0.,1.,08 
TOT= TOT + CPUCI) 
WHENEVER TOT.G.X, TRANSFER TO LLL 
CPUT=1/10, + .1*RANNO.(0) 
END OF CONDITIONAL 
INT=CPUT/ 5E -6 
TRANSFER TO RETURN 


ENTRY TO INTDEL. 

DELAY BEFORE AN INTERACTION. 12 PERCENT OF THE TIME 
AN INTERACTION HAS A ZERO CONSOLE PART (BECAUSE 

OF A PROGRAM GENERATED COMM.). THIS !S TAKEN CARE 
OF BY THE ‘RING’ ELEMENT. THE FOLLOWING DISTRIBUTION 
YIELDS A TIME BETWEEN 0 AND 2 

SECONDS WITH A PROBABILITY OF .0784 AND A TIME 
DISTRIBUTED WITH A MAX OF .05104 AT 6. (8.) 

AND A MEAN OF 41,34, ADDED TO 2. 
WHENEVER RANNO.(0).LE..0784 

INT#2E6*RANNO. (0) 
OTHERWISE 
INT=1E6*(2.+SPRAN.(.167,.8244, 358.26) ) 

END OF CONDITIONAL 
TRANSFER TO RETURN 

R 

ENTRY TO DRMDEL. 
R DELAY FOR ‘ARG' WORDS FROM DRUM. 

INT=ARG*8.4 + RANNO.(0)*17200. 

TRANSFER TO RETURN 


BDDBDADDADADA A 


R 
ENTRY TO DSKDEL. 
R DELAY FOR 'ARG' WORDS FROM DISK. 
WHENEVER RANNO.(0).G..2 
BAS 1S#20.*466. 
OTHERWISE 
BAS IS=1.4«466. 
END OF CONDITIONAL 
TOT=0. 
THROUGH L2, FOR INT=ARG+BASIS#RANNO. (0),-BASIS,INT.L.F*BASIS 
X=RANNO. (0) 
WHENEVER X.L..033 
X=50000. 
OR WHENEVER X.L..167 
X=120000. 
OTHERWISE 
X=180000, 
END OF CONDITIONAL 
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TOT=TOT+X+RANNO. (0)#34000. 


L2 CONTINUE 
INT=TOT+66.5927#ARG 
RETURN WHENEVER INT.LE.1., INT=1. 


FUNCTION RETURN FTOI.CINT) 

INTEGER FTOI.,F 
R 

ENTRY TO NOSEEK, 
R ENTRY TO SAY IF NO INITIAL DISK SEEK REQUIRED. 
F2ARG 

FUNCTION RETURN 


INTERNAL FUNCTION 

THIS ROUTINE GENERATES RANDOM NUMBERS OF TWO KINDS, 
"EXPRAN.' RETURNS A NUMBER EXPONENTIALLY DISTRIBUTED 

FROM 0 (E.P.(-X)) WITH A MEAN OF 1.0 

"DMPRAN." RETURNS A NUMBER WHICH IS DISTRIBUTED 

ACCORDING TO A DAMPED EXPONENTIAL FROM 0 (X#E.P.(-X)) WITH A 
MEAN OF 1.0. 


ENTRY TO EXPRAN, 
FUNCTION RETURN (-LOG.(1.=-RANNO.(0))) 
R 


RBDDDBDADD nD 


ENTRY TO DMPRAN, 

FUNCTION RETURN (-LOG.(RANNO,.(0)*RANNO.(0)))/2. 

END OF FUNCTION 
R 
R SUBROUTINE TO RETURN RANDOM NUMBER FROM DISTRIBUTION-- 
R PCA.P.2)(T)CEXP(-AT)) + QC(1/TAU) FOR T.LE.TAU AND 
R (A.P.2)(T) CEXP(-AT) OTHERWISE. 
R 
R PROGRAM WORKS BY PICKING UNIFORM DISTRIBUTION WITH 

R PROBABILITY Q = 1-P, EXPONENTIAL WITH PROB. P. 
R 

INTERNAL FUNCTION (A,?P, TAU) 

ENTRY TO SPRAN. 

WHENEVER RANNO.(0).G.P 

FUNCTION RETURN RANNO.(0)*TAU 
OTHERWISE 
FUNCTION RETURN 2.*DMPRAN.(0)/A 

END OF CONDITIONAL 

END OF FUNCTION 

END OF FUNCTION 
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